Apache OpenOffice (AOO) Bugzilla – Issue 95654
Can we survive .uno:CloseDoc while we have a modal dialog open
Last modified: 2013-07-30 02:17:35 UTC
Can we survive .uno:CloseDoc while we have a modal dialog open ? i.e. with the testtool and *without* OOo base installed the attached example will open the qatesttool .odb example, which will get the modal File Select dialog instead of base. In a bit testtool will give up and call .uno:CloseDoc on it. I see that the .uno:CloseDoc event get processed, deletes all windows etc, but Dialog::Execute() remains executing while ( !aDelData.IsDelete() && mbInExecute ) { Application::Yield(); } when we've finished deleting all windows and destroying everything then Dialog::Execute gets a go and dies with accessing of mpDialogImpl->mnResult. Even if we avoiding touching mpDialogImpl->mnResult when mpDialogImpl is NULL it still returns to code which is now totally screwed as some other things it depends on has gone away.
Created attachment 57576 [details] testtool script for use without base installed as an example
Basically the answer is: no. Two reasons: - dialogs are often created on the stack (e.g. error messages, warning boxes). The document cannot simply delete them or get rid of them otherwise. - closing the document while having a dialog child does something intrinsically evil: it destroys windows in the wrong order. This has to be ALWAYS child first, then parent. Also this has always been so. You may say this is a shortcoming of vcl and you'd be right, but the amount of restructuring this would require is quite some. Do fix this really we'd need to make windows refcounted. Had only this idea appeared to the creators back in windows 3.1 times, but alas, it is not so. Another way could be to at least reparent any child to the being deleted window's parent (or to the default window for that matter). The side effects however might be staggering (e.g. focus handling comes to mind). Since this involves a larger structural rework I'll call it an enhancement. And unless someone can think of simpler solution (even a good hack) I have no idea about the target.
Could we do something at a higher level than vcl in some framework area to maybe on a .uno:DoClose on a frame we actually call "cancel all modal dialogs for that frame" and at tne end post a new event of sort of .uno:DoRealClose would that in theory give a valid sequence of cancel events process handlers for cancels and then the real doclose ?
good question. First this new method would have to know the running modal dialogs (at least in vcl there should be a method to retrieve them). On these would then be called EndExecute( 0 ) (where 0 may or may not be the correct value). Then the postuser event would have to execute the real close. let's ask the framework experts whether that is feasible.
As far as I remember, the last time when we tried to reach something like this, the problem with vcl dialogs was that they had to be closed in correct order, to avoid crashes in case the dialog is already on the stack. That was workarounded by storing locally the order of vcl-dialogs if I am not wrong. Currently the dialogs started asynchronously, so now the situation could be different. But the main problem were the java dialogs, system dialogs and other non-vcl dialogs. As for the framework general solution, I do not see any general solution here. Each non-vcl dialog has to be handled separately. It is quite common situation that a frame does not know more about currently shown dialog as the vcl. Additionally, please do not forget addons that also might show dialogs. We could of course let each dialog register itself in the way that it must react to the document/frame notifications, but that would be a new API as well. And it would be no enhancement, it would be a new feature. I am actually not sure that it worses the efforts. But may be there is a nice simple way I just do not see.
oh, yes, the non vcl dialogs are a problem. Even if only vcl is involved there is another problem (in a more complicated scenario): - open document 1 - open document 2 - open modal dialog (modal to document 2) - switch to document 1 - open modal dialog (modal to document 1) - switch back to document 2 - open modal sub dialog (modal to document 2 and its already modal dialog -> the process stack of the main thread now looks somthing like this Application::Execute() Dialog::Execute() (from doc 2) Dialog::Execute() (from doc 1) Dialog::Execute() (from doc 2) You cannot really fall out of the execute for the dialog in the middle, although that is probably the smaller evil compared to a crash. Then again this is quite an elaborate example.
eek, the easier fix for me then is probably to instead just look at the qa test itself and add in a "Kontext Filter Dialog" fallbacks check before heading towards .uno:Close and pretend the problem doesn't exist :-) Feel free to close this out as "never going to happen"
I wouldn't say never, but this will probably stay with us until we switch away from vcl. Whenever that's going to be.
Reset assignee on issues not touched by assignee in more than 2000 days.