Robert Shearman rob@codeweavers.com writes:
Set the default for WM_QUERYENDSESSION to be 5s which should be enough time for users to respond to any message boxes and WM_ENDSESSION to a lower 1s.
If you are going to timeout on the user interaction you need to popup a confirmation dialog of some kind to allow users to force killing the app; you can't kill it just because the user didn't click on a "do you want to save your file?" message box fast enough.
Alexandre Julliard wrote:
Robert Shearman rob@codeweavers.com writes:
Set the default for WM_QUERYENDSESSION to be 5s which should be enough time for users to respond to any message boxes and WM_ENDSESSION to a lower 1s.
If you are going to timeout on the user interaction you need to popup a confirmation dialog of some kind to allow users to force killing the app; you can't kill it just because the user didn't click on a "do you want to save your file?" message box fast enough.
The original code seems to have been designed to not wait at all, but this got changed by a user32 commit that made a timeout of zero behave as INFINITE.
So which should it be - no timeout or timeout followed by a dialog to carry on waiting or kill the process?
Robert Shearman rob@codeweavers.com writes:
The original code seems to have been designed to not wait at all, but this got changed by a user32 commit that made a timeout of zero behave as INFINITE.
I don't think so, AFAICT it has always been supposed to wait (except with the SMTO_ABORTIFHUNG flag).
So which should it be - no timeout or timeout followed by a dialog to carry on waiting or kill the process?
Either is OK, though a timeout followed by a dialog is better. What's not OK is a timeout and then a kill while the user might be trying to save the file.