Hi Nick,
Thanks for your response. The two types of records that fall into this else
clause are ObjRecords and DrawingGroupRecords. The ObjRecord comes up
whenever auto-filtering is turned on (this case is the one in the bug) while
DrawingGroupRecords come up when uploading Excel sheets with images. I put
a break point after the while (in.hasNextRecord()) and these were the record
structures that came up in cases where this code used to fail:
1. [OBJ]
SUBRECORD: [ftCmo]
.objectType = 0x0014 (20 )
.objectId = 0x0088 (136 )
.option = 0x2101 (8449 )
.locked = true
.printable = false
.autofill = true
.autoline = false
.reserved1 = 0x00000000 (0 )
.reserved2 = 0x03AFB608 (61847048 )
.reserved3 = 0x00000000 (0 )
[/ftCmo]
SUBRECORD: [UNKNOWN RECORD:c]
.id = c
[/UNKNOWN RECORD]
SUBRECORD: [UNKNOWN RECORD:13]
.id = 13
[/UNKNOWN RECORD]
[/OBJ]
2. [MSODRAWINGGROUP]
No Escher Records Decoded
[/MSODRAWINGGROUP]
Let me know if you need any more information.
Thanks!
Sarah
On 8/17/07, Nick Burch <nick@torchbox.com> wrote:
>
> On Thu, 16 Aug 2007, Sarah Waziruddin wrote:
> > I have implemented a possible fix for bug 42844 and wanted to run it by
> > this list before going ahead. As noted in the bug, HSSFEventFactory
> > doesn't seem to handle ContinueRecord's though some ContinueRecords do
> > get to this point in the code. In particular, ObjRecord and
> > DrawingGroupRecord get to this code and I think they must be handled
> > here.
>
> Any chance you could let us know the sequence of records that's triggering
> the problem for you, and is fixed with your patch? I have a hunch that
> there might be a slightly better place for your logic to go, but I'm
> having trouble spotting it without knowing what the records are
>
> Nick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>
|