Re: [lmi] PATCH: fix "--help" for the GUI test

[Greg Chicares]

On 2014-11-17 01:42Z, Vadim Zeitlin wrote:
> On Sun, 09 Nov 2014 02:20:08 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> BTW, './wx_test.exe --help' doesn't seem to DTRT. I think it
> GC> should mention '--help' and '--data_path', but not the other two
> GC> options it shows now; and '--test' and '--list' should be added
> GC> along with any new options we add. I'm guessing that this won't
> GC> be too hard to do by analogy with Skeleton::ProcessCommandLine(),
> GC> but tell me if I'm wrong.
> 
>  I'm not sure how to use getopt library to parse and remove just some
> options while letting Skeleton::ProcessCommandLine() deal with the rest of
> them. I'd also like to avoid duplicating the description of the options
> understood by the latter in the test, they will fatally get out of sync
> with time, so if we really want to do this, I'd strongly argue for
> refactoring Skeleton first and making "long_options" available to the
> derived classes, e.g. via some simple accessor function.
> 
>  But in the meanwhile, and to avoid more changes to the main application,
> what do you think about the simple attached patch? It just intercepts
> "--help" at the GUI test level and gives a simple usage message for it.

Good enough. Committed 20141204T0240Z, revision 6041.

>  As an aside, isn't it surprising to see "untimely warning" in the message
> box displaying usage text? It's anything but untimely, as it's given in
> direct response to the users request, and it's not really a warning
> neither...

You are quite right. Apparently it arises because of this in 'skeleton.cpp':

    if(show_help)
        {
        getopt_long.usage(warning());
        warning() << std::flush;
        return false;
        }

Normally, that would just be a "Warning", which is still incorrect; it's
"Untimely", hence doubly incorrect, because it occurs while this condition
is not met (in 'alert_wx.cpp'):
    if(wxTheApp && wxTheApp->GetTopWindow())

I suppose the right way to fix it would be to call wxMessageBox() directly,
with a more appropriate title. But would that be safe, given that there is
no top window and perhaps the message loop isn't running? Well, you know
this stuff far better than I do; I'd welcome a patch.