Issue 100944 - Crash after exporting to Excel
Summary: Crash after exporting to Excel
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 3.0.1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: Frank Schönheit
QA Contact: issues@framework
URL:
Keywords: crash
Depends on:
Blocks:
 
Reported: 2009-04-08 10:09 UTC by ab
Modified: 2017-05-20 10:29 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Stack found while reproducing problem (starting macro must be finished to avoid Basic related problem) (6.60 KB, text/plain)
2009-04-08 10:13 UTC, ab
no flags Details
stripped version of the test case (15.54 KB, application/vnd.oasis.opendocument.spreadsheet)
2009-04-16 21:05 UTC, Frank Schönheit
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description ab 2009-04-08 10:09:07 UTC
ab->fs: As discussed, this is a follow up issue to:
http://www.openoffice.org/issues/show_bug.cgi?id=100834
Please look there for the description how to reproduce. 
This issue covers problem 2. mentioned there. While re-
producing I got a stack, I will attach to this issue.
Comment 1 ab 2009-04-08 10:13:00 UTC
Created attachment 61453 [details]
Stack found while reproducing problem (starting macro must be finished to avoid Basic related problem)
Comment 2 Frank Schönheit 2009-04-16 21:05:25 UTC
Created attachment 61615 [details]
stripped version of the test case
Comment 3 Frank Schönheit 2009-04-16 21:06:26 UTC
The attached document i100944.ods contains a stripped-down version of the test
case originally attached to issue issue 100834. Just open the document, and
press the "Export" button, to reproduce the crash.
Comment 4 Frank Schönheit 2009-04-22 20:14:59 UTC
fs->r_rethmann: Uhm, your SaveDocAsExcel is does a *very* nasty thing:
  oDoc.getDrawPages.getByIndex(0).Forms.dispose()
That's the source of all evil: never ever (NEVER EVER!) dispose an object which
you do not own! And in this case, you certainly do not own the forms collection.

I can probably fix the crash, but you will definitely need to adjust your macro
to reach what you intended to reach (which I assume is "removing all form
controls from the document").
Comment 5 Frank Schönheit 2009-04-22 20:21:50 UTC
fixed in CWS dba32b

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba32b
Comment 6 Frank Schönheit 2009-04-22 20:26:55 UTC
Okay, the script doesn't crash OOo anymore. I am not sure the resulting Excel
document is okay, I know too little about Excel.

In OpenOffice.org, a form control is a duality of a form control model (the ones
you see in the form navigator), and control shapes in the drawing layer, which
are associated with a control model.

The script removes all control models (and all logical forms) from the document,
but the shapes remain. When saving this as Calc document, this would result in a
document corruption (but one which OOo will silently deal with). I do not know
whether the resulting Excel documents are also corrupted.

A clean solution to remove all form controls from the document would mean to
- iterate over all shapes in the draw page
  - check which shape supports the XControlShape interface
  - remove this shape from the document
- finally remove and dispose (which is allowed then, since removal made you
  the owner) all elements of the DrawPage.Forms (*not* the Forms object
  itself)

This would leave you with a consistent document.
Comment 7 r_rethmann 2009-04-24 10:04:03 UTC
@fs: You are right, disposing the form element was nasty. Sorry for that. I've
changed that in my code according to your suggestion. After deleting the shapes
(which also automatically deletes the controls) I don't have to delete any
forms. Empty forms won't get exported to Excel anyways.
Thanks for your help!
Comment 8 Frank Schönheit 2009-05-07 08:25:41 UTC
fs->msc: please verify in CWS dba32b
Comment 9 Frank Schönheit 2009-06-03 13:26:47 UTC
re-opening, crashs again in most recent CWS build. Moving to CWS dba32e.
Comment 10 Frank Schönheit 2009-06-03 13:36:29 UTC
back to me
Comment 11 Frank Schönheit 2009-06-23 14:00:22 UTC
fixed in DEV300.m50, which is where dba32b was integrated. Seems my very last
test on this CWS (before it was integrated) used an obsolete version (well
possible given the build hassle we had), so it was indeed fixed in this CWS, as
originally claimed.