The stack trace just ends when the stack overflows, but it looks
like a getSid() call returns ­1 (this may be the error record,
although I¹d think blowing the stack would not ever return). There
are over 500 recursive serialize/getRecordSize calls before it explodes.

The two previous records return Sids of 520, so at least one "520" made
it through.  (Where in the code can one see what those sid numbers
signify?)

> What's the record you're trying to find the size of? (Should be the bottom
> one in the stack trace). In theory most of them should be fine to call
> getRecordSize(), but possibly not all, especially those with whacky
> continue records
> 

I was trying to keep track of my position in the sheet, so I
was trying to keep track of my progress by getting the size of
ALL records.  (And the app initializes using addListenerForAllRecords
so I expect a callback under any circumstances.)

The sheet I¹m parsing is quite complex so it is reasonable to
account for the possibility of anything, even though I really only
want the CSV output.

I¹ll try your ³by order² tactic.  I thought of it but wasn¹t sure it
could be guaranteed to work, being unsure of HSSF internals I thought
the safer route (an actual number) better.

Thanks,

Dave




On 9/17/08 4:26 AM, "Nick Burch" <[EMAIL PROTECTED]> wrote:

> On Tue, 16 Sep 2008, Dave Madole wrote:
>> (As far as I can tell the only way I¹ll be able to figure out what sheet
>> I¹m in using the event model is to add up the bytes and compare it to a
>> table I built from the offsets in the BoundSheetRecord records when I
>> read them.  If there¹s a simpler way--and I hoper there is--this email
>> is moot, although the stack overflow seems like a potential problem.)
> 
> Each sheet's data is started with a BOFRecord. You could sort the
> BoundSheetRecords by the order of their field_1_position_of_BOF entries,
> then track the BOFRecords of type WORKSHEET
> 
>> I get a stack overflow if I put ³getRecordSize()² in the processRecord
>> method while modifying the XLS2CSVmra example app.
> 
> What's the record you're trying to find the size of? (Should be the bottom
> one in the stack trace). In theory most of them should be fine to call
> getRecordSize(), but possibly not all, especially those with whacky
> continue records
> 
> Nick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to