Re: [lmi] [PATCH] Add undisplayable_exception

[Vadim Zeitlin]

On Fri, 24 Oct 2014 01:51:46 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2014-10-09 00:41Z, Vadim Zeitlin wrote:
GC> > On Wed, 08 Oct 2014 15:33:35 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> Perhaps the SendMessage(WM_MDISETMENU) failure for insufficient
GC> > GC> storage is merely incidental and uninteresting.
GC> 
GC> FWIW, I'm still seeing that diagnostic...more below.

 And I still don't see it, somehow, even under XP. But I think I have an
explanation for this below.

GC> I'm still seeing it with wx-3.1, running under 32-bit msw-xp-sp3:
GC>   In file ../src/msw/mdi.cpp at line 1453:
GC>   'SendMessage(WM_MDISETMENU)' failed with error 0x00000008
GC>   (not enough storage is available to process this command.).
GC> so I guess it must be an OS difference.
GC> 
GC> Not wanting to dismiss it too cavalierly, I tried moving the call to
GC> InitMenuBar() a bit later, to follow this:
GC>         frame_->Show(true);
GC>         SetTopWindow(frame_);
GC> but the same message still appears.
GC> 
GC> I cannot observe any incorrect behavior: the menu seems perfectly correct.
GC> The "not enough storage" message sounds scary, but "task manager" shows
GC> no attempt to grab appreciable RAM, and I have 2 GB free. Should we just
GC> write this off as some goofy msw defect?

 Actually it looks that it was more due to not reading the documentation[*]
carefully enough. It doesn't mention anywhere that WM_MDISETMENU handler
actually sets the last error, so it seems that we can't distinguish between
a real error in it (e.g. invalid menu or whatever) and a normal situation
when the menu is initially set and there is just no previous menu to
return.

 So I'm almost certain that this error message should be just removed
because currently it can be randomly triggered depending on a failure of
some operation done before the call to SendMessage(WM_MDISETMENU). But
just in case Microsoft adds better error reporting to WM_MDISETMENU in a
future Windows version, I think we can also keep it and just ensure it's
not triggered unless the last error is really set by the handler of this
message and I've just done it in http://trac.wxwidgets.org/changeset/78056
Please let me know if you still see this error even with this change, but
I'm relatively confident that it shouldn't happen any more.

 Thanks,
VZ

[*] http://msdn.microsoft.com/en-us/library/windows/desktop/ms644921.aspx