poi-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MSB <markbrd...@tiscali.co.uk>
Subject Re: bug in cell.setCellType(Cell.CELL_TYPE_NUMERIC) (POI 3.6)
Date Fri, 08 Jan 2010 08:08:00 GMT

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
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. 


Mark B

Filip Defoort wrote:
> On Wed, Jan 6, 2010 at 11:55 PM, MSB <markbrdsly@tiscali.co.uk> 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: user-unsubscribe@poi.apache.org
> For additional commands, e-mail: user-help@poi.apache.org

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: user-unsubscribe@poi.apache.org
For additional commands, e-mail: user-help@poi.apache.org

View raw message