You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Sarah Waziruddin <sw...@gmail.com> on 2007/08/17 00:32:19 UTC

possible fix for bug 42844

Hello,

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.  I have modified the else
clause on line 193 in HSSFEventFactory as follows:

else
                {
                    //    Sarah Waziruddin - swaziruddin@gmail.com - 8/15/07
                    //    we have hit a continue record and need to know how
to process it
                    //    this code is written from a combination of code
from 2.x poi versions
                    //    and from how RecordFactory handles continue
records

                    //    get the data from the input stream
                    short size = in.getLength();
                    byte[] data = new byte[ size ];

                    if (data.length > 0)
                    {
                        in.read(data);
                    }

                    // Drawing records have a very strange continue
behaviour.
                    //There can actually be OBJ records mixed between the
continues.
                    if ((rec instanceof ObjRecord) || (rec instanceof
TextObjectRecord))
                    {
                        DrawingRecord drawingRecord = new DrawingRecord( );
                        drawingRecord.setData(new byte[0]);

((DrawingRecord)drawingRecord).processContinueRecord(data);
                    }
                    else if (rec instanceof DrawingGroupRecord)
                    {

((DrawingGroupRecord)rec).processContinueRecord(data);
                    }
                    else
                    {
                        throw new RecordFormatException("Unhandled Continue
Record");
                    }
                }

As noted, this code borrows from the code in RecordFactory and seems to work
for the purposes of my application.  Does anyone have any objections to this
change or suggest another approach to fixing this bug?

Thanks,
Sarah

Re: possible fix for bug 42844

Posted by Nick Burch <ni...@torchbox.com>.
On Fri, 17 Aug 2007, Sarah Waziruddin wrote:
> 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 think this should now be fixed in svn. The xls file from bug 42844 can 
be processed in a unit test, so hopefully your excel sheet will work too.

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org


Re: possible fix for bug 42844

Posted by Sarah Waziruddin <sw...@gmail.com>.
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 <ni...@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
>
>

Re: possible fix for bug 42844

Posted by Nick Burch <ni...@torchbox.com>.
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