Enums used for getErrorStyle() are 1,2,3, while the list allowed for setErrorStyle() is built up on values 0,1,2. If you want to retrieve the error style of a data validation and apply it to another data validation a "-1" is necessary to apply it correctly. i.e : newDataValidation.setErrorStyle(anotherDataValidation.getErrorStyle() - 1);
Looks like we're using int constants rather than true enums here. This should be a pretty trivial fix: 1. Fix off-by-one getter or setter 2. Add DataValidationErrorStyle enum (or something similar) 3. Add enum versions of the accessors: > DataValidationErrorStyle getErrorStyleEnum() > void setErrorStyle(DataValidationErrorStyle errorStyle) Are you interested in tackling this and submitting a patch or pull request? https://poi.apache.org/apidocs/org/apache/poi/ss/usermodel/DataValidation.html
where can i read the correct behavior to provide you a patch ?
Principle of least surprise. Look through the JavaDocs and maybe the HSSFDataValidation class to see if there's a preference for 0-based indexing or 1-based indexing for getting and setting error styles. If there's no preference, pick the one that you think will break fewer users' code (maybe we're 50/50 on this one, I don't know). What error_style numbers are saved in the XML files of an XLSX file? What numbers are used for the HSSF binary record? If all else is equal, the enum to int code will be simplest if we use 0-based indexing.
POI patching guidelines: http://poi.apache.org/guidelines.html#SubmittingPatches I've used the OOXML specs from here: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html (search the page for "open document") +1 for using zero-based systems if possible.
hi everyone, thank s for your replies. After a walkaround inside the librery, i ve found out that the Interface "DataValidation" works with enum type in a range of 0-2. public interface DataValidation { /** * Error style constants for error box */ public static final class ErrorStyle { /** STOP style */ public static final int STOP = 0x00; /** WARNING style */ public static final int WARNING = 0x01; /** INFO style */ public static final int INFO = 0x02; } ... I think the right way to improve a solution is to get fit to this scenario. To do it i've dug more inside and i ve found out that the XSSFDataValidation getErrorStyle depends on STDataValidationErrorStyle. public interface STDataValidationErrorStyle extends XmlString { int INT_STOP = 1; int INT_WARNING = 2; int INT_INFORMATION = 3; ... This class is inside the external dependency ooxml-schemas-1.3-sources.jar, so in order to provide a patch i need the privilege to edit the source file. If you havge more suggestions i'll be pleased to hear them
STDataValidationErrorStyle is generated code, generated from the OOXML schema. The DataValidationErrorStyle cannot reference the ST* enum if it's also used by HSSF, since we don't require users to have the poi-ooxml.jar or poi-ooxml-schemas.jar files in their classpath if they're using the binary formats. I was thinking about using a true enums rather than an interface or class to contain the constants. It'd then be up to XSSFDataValidation to convert between DataValidationErrorStyle and STDataValidationErrorStyle. Likewise, HSSFDataValidation would have to provide its own translation from enum to bytes.
(In reply to Javen O'Neal from comment #6) > STDataValidationErrorStyle is generated code, generated from the OOXML > schema. In case I wasn't clear here, we're using the official OOXML xsd schemas released by Microsoft, do we don't want to edit the schemas. Also, take a look at bug 59836 and its "depends on" bugs, which tracks the enum conversion initiative that has been going on for the last few releases.
patch proposal added ( task 60870 )
Bug 60870 handles the same thing now and has a patch, we should not keep two issues open here. *** This bug has been marked as a duplicate of bug 60870 ***