Issue 109205

Summary: office hangs after showing modal dialog(s) through ole
Product: General Reporter: netforce1 <d.de.wit>
Component: uiAssignee: AOO issues mailing list <issues>
Status: UNCONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: elish, issues, oliver.brinzing
Version: OOo 3.1.1Keywords: needhelp
Target Milestone: ---   
Hardware: PC   
OS: Windows, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
simple vb.net project used to reproduce the issue
none
sample document to reproduce the issue none

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.