Re: [lmi] How can I suppress an error message from wx?

[Vadim Zeitlin]

On Sat, 14 Mar 2009 16:59:32 +0000 Greg Chicares <address@hidden> wrote:

GC> To test diagnostics in the 20090314T1609Z change to lmi HEAD, I apply
GC> the first patch below [1] to simulate an error. When I start lmi and
GC> press F1, I see:
GC> 
GC> | Unable to open
GC> |     file://C:\opt\lmi\data\user_manual.html
GC> | in default browser.
GC> |
GC> | The user...
GC> 
GC> The '...' ellipsis is copied literally: it doesn't signify any
GC> abbreviation on my part.

 Very strange. I see this:

Unable to open
    file://p:\Progs\MassMutual\bzr\msvc\user_manual.html
in default browser.

The user manual can be read online here:
    http://lmi.nongnu.org/user_manual.html


GC> Clicking "Details" shows this in addition:
GC> 
GC> | Failed to open URL "C:\opt\lmi\data\user_manual.htmlx" in default browse
GC> | Unable to open    file://C:\opt\lmi\data\user_manual.html in default brows

 This is also what I see (except for different paths).

GC> I can see a little more if I stretch the dialog box horizontally:

 The need to resize the dialog is unfortunate but OTOH it would be ugly to
make it (much) wider than necessary to show the last error message in its
not-expanded state. Maybe we should wrap the detailed messages to the
dialog width though...

GC> | Failed to open URL "C:\opt\lmi\data\user_manual.htmlx" in default 
browser. (error 2: the...
GC> | Unable to open    file://C:\opt\lmi\data\user_manual.html in default 
browser. The user...
GC> 
GC> but stretching it further doesn't lengthen the abbreviated text.

 I don't see how is this possible but it seems like the message string
itself was truncated somewhere before it got to wxLog.

GC> I know I can see the unabbreviated text by clicking "Copy" and pasting
GC> to an editor, but we cannot ask end users to do that.

 Do you actually see the unabbreviated text if you do this? If my
hypothesis above is correct you shouldn't.

GC> I tried suppressing it in the second patch below [2], hoping that
GC>   original = SetActiveTarget(0);
GC>   wxFunctionThatDisplaysAnErrorMessage();
GC>   FlushActive();
GC>   SetActiveTarget(original);
GC> would discard the wx message, but that didn't work.

 It's indeed surprising that this doesn't work but the reason for it is
that wxLog automatically creates a default log target if the current one is
NULL. So not only the patch [2] doesn't work but it also leaks memory
(because the auto-created log target is leaked when you restore 'z' without
deleting the return value of SetActiveTarget()).

 This approach could be made to work with wxLog::DontCreateOnDemand() but
wxLogNull solution which you already discovered independently is simpler
and better.

GC> Neither did an experiment with Suspend() and Resume().

 This is less surprising: Suspend() doesn't suppress logs, it just
postpones (until Resume() is called) showing them.

 I hope I could explain wxLog behaviour, please let me know if you have any
questions,
VZ