Hello Filip, Yes, but assuming the code found two or more suitable formats which should it then apply? I am not arguing that the API should not be modified because I do agree with you that the setCellType() method should not fail. Instead, I think that it can only be expected to offer the most basic of support; the "$2,500" dollar example should be converted to 2500 in my opinion - assuming a change from String to numeric - and it should be the developers' responsibility to define and apply a suitable format.
With regard to getStringCellValue() I both agree and disagree. If you take a look through the documentation for the org.apache.poi.ss.usermodel.DataFormatter class, you will see that it already defines methods to do pretty much what you require http://poi.apache.org/apidocs/org/apache/poi/ss/usermodel/DataFormatter.html#formatCellValue%28org.apache.poi.ss.usermodel.Cell%29. So, I agree that what you suggested would be usful but do not think that the getStringCellValue() method needs to be modified owing to the DataFormatter class; if it does not meet your exact requirement, then it should be possible to create a specialised subclass to handle this. Yours Mark B Filip Defoort wrote: > > On Wed, Jan 6, 2010 at 11:55 PM, MSB <[email protected]> wrote: >> >> Yes, that would work for your requirement Filip but I can easilly imagine >> another using say that the String value "$2,500" should be converted to a >> number and a format should be generated and applied automatically to the >> cell so that they did not lose the dollar sign and comma separator - and >> is >> this really the function of a setCellYtpe() method? I think that we could >> convincingly argue that if you try to convert a cell whose type is text >> or >> string into a numeric cell (for example) then a warning should be issued >> that information may be lost. In my opinion, it will not be possible to >> catch and handle every little requirement, so the conversion of the value >> should be performed and the user ought to be warned that changes may >> occur >> to the appearence of the cell. > > It probably wouldn't be that hard to loop over the data formats and > see which ones fit and convert. A warning would indeed be nice or an > extra parameter to the setCellType() method. > > E.g. setCellType(Cell.TYPE*, boolean convert) > > In either case, calls to setCellType() shouldn't fail. > > On a somewhat related topic: I'm really surprised that calls to > .getStringCellValue() fail if the type of a cell is not string. It'd > seem logical to me to return a string representation of the cell's > value (or to have another method called .getCellDisplayValue() or > something like that so a user has a single method they know they can > always call to get the value of a cell without needing switch > statements all over the code to handle variations). > > Cheers, > - Filip > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- View this message in context: http://old.nabble.com/bug-in-cell.setCellType%28Cell.CELL_TYPE_NUMERIC%29-%28POI-3.6%29-tp27034280p27072580.html Sent from the POI - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
