Its covered in the howto which is here: http://jakarta.apache.org/poi/hssf/how-to.html
Certainly the usermodel api is easier to use. The event based API cuts memory usage by some order of 10 though. We intend (partially by necessity) to continue supporting both as the event api is read only... I certainly encourage anyone reading large sheets to use the eventmodel though. Example: A 4mb sheet takes over 50 mb of memory to process with the usermodel.. The same sheet takes 7 mb (and thats probably mostly vm overhead) to process with the eventmodel. -andy >On Wed, 27 Feb 2002 22:01:59 0100 "Reto Badertscher" <[EMAIL PROTECTED]> wrote. >Hello Andy, >I'll investigate in the event based API. From where can i get more >information for using the event API - the User API is very simple to >understand and implement and as ever i have to deliver a solution as quick >as possible. > >Thanks for your help > >Reto >-----Ursprungliche Nachricht----- >Von: acoliver [mailto:[EMAIL PROTECTED]] >Gesendet: Mittwoch, 27. Februar 2002 19:14 >An: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >Betreff: Re: HSSFRow.getLastCellNum() > > >>On Wed, 27 Feb 2002 19:04:08 0100 "Reto Badertscher" <[EMAIL PROTECTED]> >wrote. >>Hello, >> >>just started using POI for reading, writing and modifying Excel sheets and >>like it very much. Until now i've been using Perl libraries for these >tasks. >>During creating some test applications i encountered the following problem: >>When a HSSFRow has empty cells the method 'getPhysicalNumberOfCells()' >>returns the number of cells with values and the method > >That is correct behavior > >'getLastCellNum()' >>returns 0, regardless of the number of cells. According to my understanding >>it should return the number of the last cell containing a value - or do i >>missing something? > >Nope.. This is a known bug. I believe Glen has fixed it (Glen?) and it >should be in the next production release (1.5) soon. You could also use the >CVS edition. I'd suggest you investigate using the event based API for >reading. Although it is more *difficult*, it is far more efficient by some >order of 10 as far as memory goes. > >-Andy > >>Version: 1.0.2 >>JDK: 1.3.1_01 >>Platform: Windows 2000 SP 2 >> >>Thanks for any help >> >>Reto >> >
