Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Openoffice crashes when using Data Source Administration. | ||
---|---|---|---|
Product: | gsl | Reporter: | Unknown <non-migrated> |
Component: | code | Assignee: | marc.neumann |
Status: | CLOSED FIXED | QA Contact: | issues@gsl <issues> |
Severity: | Trivial | ||
Priority: | P3 | CC: | issues |
Version: | OOo 1.0.1 | ||
Target Milestone: | OOo 1.1 Beta | ||
Hardware: | PC | ||
OS: | Other OS | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
Unknown
2002-08-08 15:43:56 UTC
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 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/ |