[PATCH setup] Make sure that fatal error messages are visible
Thu Dec 21 22:55:00 GMT 2017
On 12/20/2017 12:09 PM, Ken Brown wrote:
> On 12/20/2017 11:19 AM, Jon Turney wrote:
>> On 19/12/2017 00:53, Ken Brown wrote:
>>> The message box produced by TOPLEVEL_CATCH could be hidden by whatever
>>> window was previously being displayed, so that setup appeared to hang.
>>> Fix this by giving fatal error message boxes type MB_SETFOREGROUND.
>> This is good as far as it goes, but is kind of working around the fact
>> that fatal() is being called with an NULL owner HWND.
>> This is not idea because I guess it means that propsheet window is
>> still activate-able when this messagebox is displayed (MB_APPMODAL
>> doesn't apply)?
> It turns out that MB_SYSTEMMODAL did the job.Â I tried MB_APPLMODAL and
> MB_TASKMODAL also, but both of those still allowed me to activate the
> propsheet window.
I just discovered that MB_SYSTEMMODAL doesn't prevent activation of the
propsheet in all circumstances. I tried the following: I created a
corrupt local package in the local cache and then tried to reinstall the
package. This led to an exception thrown by check_for_cached(), which
normally would be caught by do_download_thread(). But I disabled that
@@ -278,8 +278,8 @@ do_download_thread (HINSTANCE h, HWND owner)
catch (Exception * e)
// We know what to do with these..
- if (e->errNo() == APPERR_CORRUPT_PACKAGE)
- fatal (owner, IDS_CORRUPT_PACKAGE, pkg.name.c_str());
+ // if (e->errNo() == APPERR_CORRUPT_PACKAGE)
+ // fatal (owner, IDS_CORRUPT_PACKAGE,
// Unexpected exception.
As I result the exception was caught by the TOPLEVEL_CATCH for the
download thread. When the fatal message box was shown, I was still able
to interact with the download progress reporting window. Fortunately,
the only available button there was 'Cancel', so no harm was done.
In spite of this, MB_SYSTEMMODAL is still the best option I've been able
to come up with.
More information about the Cygwin-apps