Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||office hangs after showing modal dialog(s) through ole|
|Component:||ui||Assignee:||AOO issues mailing list <issues>|
|Status:||UNCONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||elish, issues, oliver.brinzing|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description netforce1 2010-02-12 12:16:27 UTC
For some of our customers we integrate OOo with external applications through COM / ole automation. These applications often show modal dialogs (that also block the OOo gui). Sometimes, after such a dialog is closed, the office frame that initiated the call to the external application is blocked. It seems the frame is still waiting for the basic thread to complete. This behavior is only observed when the basic-code calling the external application is executed as a result of a toolbar-button being invoked.
Comment 1 netforce1 2010-02-12 12:17:48 UTC
Created attachment 67779 [details] simple vb.net project used to reproduce the issue
Comment 2 netforce1 2010-02-12 12:18:26 UTC
Created attachment 67780 [details] sample document to reproduce the issue
Comment 3 netforce1 2010-02-12 12:33:04 UTC
I attached some files that can be used to reproduce the issue. - One simple project in vb.net that shows a very simple modal dialog. This project builds a dll that can be installed using the regasm-tool from .Net. (regasm ModalTest.dll /tlb:ModalTest.tlb /codebase), the dll can be unregistered by invoking 'regasm ModalTest.dll /unregister'. The directory ModalTest/bin contains a ready built dll that can be registered. - An ODT-file that contains the basic-macro to reproduce the issue. This document contains a toolbar-button (ModalOleTest), and some form-controls that are used for reproducing. We found that it is not very simple to predict when the issue will occur, sometimes after one dialog is shown, sometimes it will need 10, 20, or maybe more dialogs. So we tried to show the dialog 100 times, and that almost always reproduces the issue, this amount of dialogs can be configured in the document using the inputfield with spinbuttons in the document. Next to this inputfield you'll find a button that launches a macro that calls the dialogs, when this button is used we were not able to reproduce the issue. But when the toolbar- button is used we were always able to reproduce the issue. -- So, finally some steps how the reproduce this ;) 1. Register the dll as described above 2. Open the testcase-document with macros enabled 3. make sure the value of the inputfield in the document is at lease 100 4. click the toolbar-button 'ModalOleTest' 5. Hang on the Esc-key, until you see no more dialogs (the counter in the top- left corner of the document does now read the value put in the inputfield) 6. Now, the frame is blocked. It can be dragged around, but does not react to any input.
Comment 4 netforce1 2010-02-12 12:53:06 UTC
Just verified that we can still reproduce this issue on OOo 3.2, but I cannot choose this version in the Issue Tracker.
Comment 5 Oliver Brinzing 2010-02-12 17:06:18 UTC
> This behavior is only observed when the basic-code calling the external > application is executed as a result of a toolbar-button being invoked. have you tried to add some WAITS (Thread.sleep() etc.) in your code ? we had problems with frozen frames too, when calling external c++ dialog's via toolbar button's. calling the dialog via menu entries always worked ... we added some wait's (about 0,5 sec) and the problems were gone ;-)
Comment 6 netforce1 2010-02-15 07:55:13 UTC
> have you tried to add some WAITS (Thread.sleep() etc.) in your code ? > we had problems with frozen frames too, when calling external c++ dialog's > via toolbar button's. calling the dialog via menu entries always worked ... > we added some wait's (about 0,5 sec) and the problems were gone ;-) In my testcase the problem also appears when the dialog is called through a menu entry. We tried putting waits (and msgboxes) before showing the dialog, that seemed to resolve the problem at first, but it only took a little longer before it appeared.