In many cases, ContinueRecords will be dissolved by RecordInputStream when the prior record is constructing itself (as the prior record asks for data beyond its data-size, RecordInputStream automatically grabs more data from the following ContinueRecord).
If a ContinueRecord hangs around, it is for one of 3 reasons: (a) POI is totally unaware of the previous record type (i,e, UnknownRecord). (b) POI has some logic error while reading the prior record and does not consume the following ContinueRecord in the right way. (c) Some badly behaved application has put/left a ContinueRecord in the wrong place. The fact that your problem goes away when Excel saves the file suggests reason (c). Before making a fix, it is helpful to characterise the problem better (otherwise the resulting 'solution' may end up making other bugs downstream more difficult to solve). As far as BiffView is concerned, the offending ContinueRecord should appear as-is. Text search for "CONTINUE". This should find it. If there are too many ContinueRecords in the dump, you can help locate the offending record by putting a breakpoint at RowRecordsAggregate.java:87. When you hit the breakpoint, inspect the RecordStream rs. You should be able to drill down to the recently read records. You might find some specific data nearby that helps you locate the section of the BiffView dump that has the offending ContinueRecord. Once you find that record, if you could cut out a section of the dump including several records before and after. If possible, grab everything from the prior DIMENSIONS record to the next WINDOW2 record. Hopefully you won't have too much data that needs sanitising. -josh --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
