--- [EMAIL PROTECTED] wrote:
> This will break existing code. Very Bad Thing! Also,
> with my Alan Cooper fanboy
> hat on, I think recommending to /prefer/ calling
> setCellType() is in itself a Bad Thing.
It wouldnt break existing code since existing code
would be throwing CastClassException anyway :) But I
get your point and am glad we had this discussion.
>
> I would say, add a method called
> setCellFormulaResult() overloaded for
> string/num etc.
Yeah, probably a better option! Although maybe, I can
do something like:
Create inner nested class Formula which has the
overloaded setCellFormulaResult(..) methods (& a
constructor that takes in the formula string)... and
add setCellValue(HSSFCell.Formula f) to HSSFCell. This
will keep the HSSFCell api clean since it will just
add two methods (getFormulaValue/setCellValue(Formula
f) - and I can make the javadocs very clear about
how/when to use these method :)
> I am sure we can fix the class cast exception on
> calling setCellFormula
> followed
> setCellValue independently.
True. I should have thought of that! :) So now in
setCellValue(..) methods we can change:
if ((cellType != CELL_TYPE_STRING )
&& (cellType != CELL_TYPE_FORMULA))
{
setCellType(CELL_TYPE_STRING, false);
}
--TO--
if ((cellType != CELL_TYPE_STRING ))
{
setCellType(CELL_TYPE_STRING, false);
}
[Since we will have a setCellValue(Formula f) that
will take care of the formula with initial value]
Regards,
~ amol
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List: http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
