[gsl-issues] [Issue 95654] Can we survive .uno:CloseD oc while we have a modal dialog open
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=95654 --- Additional comments from [EMAIL PROTECTED] Fri Oct 31 10:14:39 + 2008 --- I wouldn't say never, but this will probably stay with us until we switch away from vcl. Whenever that's going to be. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[gsl-issues] [Issue 95654] Can we survive .uno:CloseD oc while we have a modal dialog open
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=95654 --- Additional comments from [EMAIL PROTECTED] Fri Oct 31 09:13:28 + 2008 --- 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" - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[gsl-issues] [Issue 95654] Can we survive .uno:CloseD oc while we have a modal dialog open
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=95654 --- Additional comments from [EMAIL PROTECTED] Thu Oct 30 18:32:21 + 2008 --- 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[gsl-issues] [Issue 95654] Can we survive .uno:CloseD oc while we have a modal dialog open
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=95654 --- Additional comments from [EMAIL PROTECTED] Thu Oct 30 18:16:13 + 2008 --- 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[gsl-issues] [Issue 95654] Can we survive .uno:CloseD oc while we have a modal dialog open
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=95654 User pl changed the following: What|Old value |New value CC|''|'as,cd,mav' --- Additional comments from [EMAIL PROTECTED] Thu Oct 30 17:22:26 + 2008 --- 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[gsl-issues] [Issue 95654] Can we survive .uno:CloseD oc while we have a modal dialog open
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=95654 --- Additional comments from [EMAIL PROTECTED] Thu Oct 30 16:53:27 + 2008 --- 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 ? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[gsl-issues] [Issue 95654] Can we survive .uno:CloseD oc while we have a modal dialog open
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=95654 User pl changed the following: What|Old value |New value Issue type|DEFECT|ENHANCEMENT OS/Version|Linux |All Target milestone|--- |OOo Later --- Additional comments from [EMAIL PROTECTED] Thu Oct 30 15:18:39 + 2008 --- 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[gsl-issues] [Issue 95654] Can we survive .uno:CloseD oc while we have a modal dialog open
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=95654 --- Additional comments from [EMAIL PROTECTED] Thu Oct 30 14:38:22 + 2008 --- Created an attachment (id=57576) testtool script for use without base installed as an example - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[gsl-issues] [Issue 95654] Can we survive .uno:CloseD oc while we have a modal dialog open
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=95654
Issue #|95654
Summary|Can we survive .uno:CloseDoc while we have a modal dia
|log open
Component|gsl
Version|DEV300m34
Platform|All
URL|
OS/Version|Linux
Status|NEW
Status whiteboard|
Keywords|
Resolution|
Issue type|DEFECT
Priority|P3
Subcomponent|code
Assigned to|pl
Reported by|cmc
--- Additional comments from [EMAIL PROTECTED] Thu Oct 30 14:37:41 +
2008 ---
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.
-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
