Re: [lmi] Displaying messages during wx startup

[Greg Chicares]

On 2009-03-27 23:56Z, Vadim Zeitlin wrote:
> On Fri, 27 Mar 2009 12:15:18 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Consider the patch below, which attempts to display a warning message
> GC> on the first line of the main function. Is there some way to make the
> GC> wxLogWarning message get displayed, even before wx has been initialized?
> GC> I suspect the answer is "no",
> 
>  I'm afraid currently it is although to be honest I don't have any
> reasonable explanation as to why is it so -- wx surely could use
> MessageBox() under Windows internally to ensure that the log messages are
> always shown. I think it would be worthwhile to change wxLog to use
> wxMessageOutputMessageBox instead of wxLogStderr by default in GUI MSW
> programs, what do you think?

I agree.

> GC> which is okay by me as long as I can find a way to test whether it's
> GC> not going to work--is there a way?
> 
>  There is but it's a rather roundabout one: wxLog target used by default
> can be customized by overriding wxApp::CreateTraits() method to return a
> custom wxAppTraits-derived object which, in turn, overrides its
> CreateLogTarget() method. So if you define your own LMIAppTraits doing this
> you could simply set a flag in your overridden CreateLogTarget() and then
> just call the base class version. And then you could use this flag to check
> if the real GUI log target was already created.

I guess I'd prefer a simpler method than that.

>  A much simpler but somewhat uglier method might be to check if
> dynamic_cast<wxLogGui *>(wxLog::GetActiveTarget()) is non-NULL.

Ah. The dynamic_cast is what I was missing in this suppressed
(and incorrect) function in 'alert_wx.cpp':

#if 0
    /// Alert messages could be lost if they're flushed before wx has
    /// initialized its logging facility. Here is an untested idea for
    /// a function that could be called prior to each use of that
    /// facility in this file. It's probably not correct to rely on
    /// the particular condition tested here, though.
    void show_safely_if_log_uninitialized(std::string const& s)
        {
        if(0 == wxLog::GetActiveTarget())
            {
            safe_message_alert(s.c_str());
            }
        }
#endif // 0

Thanks--now I know how to make that technique work.

>  But neither of these hacks would be needed if wx just did the right thing
> itself and always ensured that the message is shown. Do you see any reason
> why it shouldn't do this?

I agree that the wx change you propose sounds really good.

I'll still want to make some changes to lmi:

 - to get the desired behavior in lmi production now, with wx.2.8

 - to fix some really awful problems waiting to happen in case
   wxTheApp is null, e.g., here:

    wxWindow* w = wxTheApp->GetTopWindow();
    wxLogStatus(dynamic_cast<wxFrame*>(w), s.c_str());

 - to avoid another really awful problem that you point out below,
   because such a crash which might take days to track down

> GC> // from 'alert_wx.cpp':
> GC> void warning_alert(std::string const& s)
> GC> {
> GC>     wxLogWarning(s.c_str());
> GC>     wxLog::FlushActive();
> GC> }
> 
>  This is completely OT but important enough to be mentioned IMO: I don't
> know if there is some code elsewhere ensuring that 's' doesn't contain any
> percent characters but even if there is it would still be much safer to use
> wxLogWarning("%s", s.c_str()) here. Otherwise any occurrence of "%s" in the
> string is almost certain to produce an immediate crash and any occurrence
> of anything else (e.g. "%d" or "%g" or whatever) is even more pernicious as
> it's going to corrupt the stack and will result in a crash in an unrelated
> location.