Summary: | Excel file causes InvocationTargetException | ||
---|---|---|---|
Product: | POI | Reporter: | Dan McConnell <dmccon1957> |
Component: | HSSF | Assignee: | POI Developers List <dev> |
Status: | RESOLVED WONTFIX | ||
Severity: | critical | ||
Priority: | P3 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Attachments: |
Excel file
Patch for fixing the runtimeerror caused by the xls attached to this bugreport |
Description
Dan McConnell
2004-05-04 17:50:23 UTC
Created attachment 11426 [details]
Excel file
This looks like a simple case of writing a bad record (95 format record?) either that or we read it wrong.... Created attachment 15801 [details] Patch for fixing the runtimeerror caused by the xls attached to this bugreport Andy is probably right. However since a runtime exception is caused, is it a BadThing to let it happen? The attached patch attempts to fix the runtime exception by setting default values in case the array runs out of data in fillFields(..). The patch was tested on the previous attachement to this issue (attachment#11426 [details]) and was found to be working. It seemed to work for both load and save file. Also passed the previously broken test in usermodel/TestUnfixedBugs I'm -1 on that until its confirmed that the record is a Biff8 record. If it is a Biff 7 or previous we should throw an exception and say "Not a valid Excel 97+ file" -- Someone needs to do a org.apache.poi.hssf.dev.BiffViewer to check (probably after commenting the thing out of the RecordFactory to get the hex dump) out what all is different. We shouldn't punt on correctly reading the record and just "make it work"...we need to read it correctly. Its okay to write something different. Yup this is a BIFF 5/7 file and not a BIFF 8. The BOF record is 12 bytes. A BIFF 8 BOF record should be 20 bytes. Jason |