Apache OpenOffice (AOO) Bugzilla – Issue 6853
Openoffice crashes when using Data Source Administration.
Last modified: 2003-02-20 11:08:42 UTC
Error Message ============= The instruction at "0x00402f86" referenced memory at "0x0061018a". the memory could not be read. An exception 'Unhandled Win32 Exception' has occurred in soffice.exe. Also 'An unrecoverable error has occurred. All modified files have been saved and can probably be recovered at program restart'. Then it gives the above error (see notes further down). Environment =========== PC Windows NT4 Service Pack 6 OpenOffice 1.0.1 Symptoms ======== Produces the above error and closes down the app (even the quickstarter). How to reproduce. ================= Start up Writer. Click the data sources button. Right click on Bibliography and select 'Administrate Data Sources'. Click on the empty document then click the data sources button to remove the Data Sources window. This leaves the Data Source Administration window open. I tried to close the Data Sources window by clicking on the Data Sources button but this did not close it. I found if I clicked on the document the the button the Data Sources window closed. Click on the Data Sources Administration window (I moved it round a bit). I am not sure if this is necessary but I did it when the error was produced. Open up a new Writer document. Click on the Data Source Administration window or move it a bit. Bingo - The error is produced. Also instead of opening up a new Writer document just go and play around with the Data Source Administration window tabs etc. This will produce a 'An unrecoverable error has occurred'. Thoughts ======== It looks like the Data Source Administration window is Modal as other buttons seem to be non functioning. This makes sense. However by clicking on the document it seems to lose its modal status and the buttons on the toolbar workwork (e.g. Graphics on/off). I can duplicate this every time.
could reproduce To me, the problem seems to be the clickable button in the toolbox
argh. Have to submit a bug for issuezilla I think. checking "reassign" and "confirm" does neither confirm nor reassign, if the owner is not changed
hmm. this time it worked, so it's only me :) Anyway, assigning this to the VCL guys. I know they had problems with this effect (clickable toolboxes when a modal dialog is open), and this is fixed in the latest internal builds. Stephan, perhaps you should consider this fix for 1.0.2 ....
forgot to change the component/QA contact, and this time the real new owner (hopefully)
The problem is that the dialog is not modal to the document window, but only to the database beamer. When you toggle the floating mode of the beamer by pressing the pin before you open the dialog everything is fine. This is due to the temporary floating window used as parent when the window is not fixed. As an easy workaround do not set any parent at all when constructing the dialog, i.e., pass NULL! This will select the famous DefModalDialog Parent which guarantees modality to the document window. Please do so for all dialogs opened from the database beamer. The gallery does the same, by the way.
To be honest, I do not like the idea of passing NULL. This DefModalDialogParent is something which causes us trouble again and again, and I do not want to introduce yet another potential problem here. Instead, I will go up the XWindow chain in the data source browser, until I reach a frame which returns isTop() == true. This should give us the proper parent explicitly, instead of relying on implicit magics :).
Ocke, please care for this. We should try the approach sketched above: go up the frame chain until we find an XTask which's isTop returns true, and use this frame's (container or content) window as parent. Thanks
I could not reproduce this behaviour in the latest builds, however, I am not really happy with the problem simply vanishing. Ocke, to be on the safe side, we should change SbaTableQueryBrowser::implAdministrate so that it uses the top-most window of the task it resides in (just step up the window chain). This should prevent this bug from re-occuring. Could you please care for this?
Fixed
Reopen because need to reassign this to QA
fixed in next developer release
verified in next internal developer release
fixed in public 644 m build see http://www.openoffice.org/dev_docs/source/644/