Biff 8 only. We don't support pre-excel 97. Basically if someone's excel is that old, well...they probably are running jdk 1.0 anyhow ;-)
Avik Sengupta wrote: >>NP. The only style that really is an issue for me is liberal sprinkling >>of Javadoc. >> > >Yeah, sure, no arguments. I've been excited to get some stuff up and running, >so obviously took lots of short cuts .. my first submission for the parser >looked more like pascal code! > >Todays patch will be cleanups, javadocs and tests, and maybe a working formula >viewer. > >Regards >- >Avik > > >PS. i wanted to know, should we be writing biff7 or biff8? > > >Quoting "Andrew C. Oliver" <[EMAIL PROTECTED]>: > >>Avik Sengupta wrote: >> >>>I have attached my latest patches to bugzilla that adds the ability to do >>>floats. All existing tests pass .. i will write up new tests for floats soon >>> >>.. >> >>>promise :) >>> >>I found writing tests first was kind of fun and useful. Make a failing >>test and watch it succeed as you make more POI. Of course I coudln't >>do this everywhere. Plus Glen will love you. (that may be a downside ;-) >>) >> >>>I have added a new NumberPtg.java, modelled on the existing records and Ptg. >>> >>>Tell me if its messed up somehow. (My knowledge of HSSF internals can only >>> >>go >> >>>up at the moment :) >>> >>Will look at it in about 5 hours or so. I'll patch and test. I'm >>really excited about the code you've been submitting. >> >>> >>>I have also changed one line in the areareference code in FormulaParser to >>> >>go >> >>>better with the style of the rest of the class. hope you dont mind. >>> >>NP. The only style that really is an issue for me is liberal sprinkling >>of Javadoc. I LOVE IT! We'll need to bring this stuff up to snuff >>soon. See: >> >>http://jakarta.apache.org/poi/resolutions/res001.html for details. We >>also need to start making sure that unit tests are heavily utilized. >> Believe me, if you think its pedantic now....you won't later. Every >>problem I've had trouble tracking down was in an un-unit tested class. >> For instance adding formulas put in a variable sized cell value record. >> Well that broke things in HSSF. Guess what....no unit tests for that >>section of code....doh! So they are absolutely essential for this >>project. As new things develop old assumptions prove false and unit >>tests are the best way to know immediately! >> >>>Andy, a couple of questions for you... >>> >>>1. Can we remove the toFormulaString(Ptg[] operands) method, and keep only >>> >>the >> >>>String[] ones? To do a recursive evalutation of an RPN ptg array, you need >>> >>the >> >>>String one. i cant find an use case for the ptg[] method. >>> >>Yes. >> >>>2. Can we remove the getStringLength method? i dont understand where it is >>> >>>used. >>> >>If you're not using it lets remove it. I did my best to trim the tree >>but may have missed a couple spots. >> >>>Thanks >>>- >>>Avik >>> >>>PS. having added the cell ref and area ref code to the parser, i hope you >>> >>agree >> >>>that its simple :) >>> >>Yes. There are a few things I may still want to move off into the PTG >>classes, but I've abandoned my earlier approach in favor of yours. (I >>think you've started doing this anyhow from a quick glimpse of your >>patch). Basically, the way I work is, "find the best approach" and I >>think you've done it. So I'm excited to be working with you on this. >> Keep it up. >> >>-Andy >> >> >> > > >
