[lmi] Using wxLogStderr [Was: NDEBUG]

[Greg Chicares]

On 2014-10-26 16:29Z, Greg Chicares wrote:
[...]
> brings us by a commodius vicus of recirculation back to
>   http://docs.wxwidgets.org/trunk/classwx_log_stderr.html

I think the line I want to add is
  wxLog::SetActiveTarget(new wxLogStderr);
but I'm not sure where to write it.

Here's my testcase:
  /opt/lmi/bin[0]$./lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data 
>/dev/null
  Test | Test system command
  type "riverrun" without quotes
  OK
Expected outcome:
  a single messagebox (same as with HEAD), saying:
    Command 'riverrun' not recognized.
  on stderr:
    HH:MM:SS: Error: Execution of command 'riverrun' failed (error 2: the 
system cannot find the file specified.)

My first attempt tries to start logging almost as early as possible:
in the ctor. I figured this would even give me diagnostics (if any)
from calling, say, wxConfigBase::Get(). Yet the outcome isn't what
I expected: instead, nothing is written to stderr, but the message
expected on stderr, which would normally not be displayed at all,
appears in an extra messagebox. I wouldn't mind knowing why this
doesn't do what I expected:

Index: skeleton.cpp
===================================================================
--- skeleton.cpp        (revision 5998)
+++ skeleton.cpp        (working copy)
@@ -191,6 +191,7 @@
     ,frame_           (0)
     ,timer_           (this)
 {
+wxLog::SetActiveTarget(new wxLogStderr);
     SetAppName("lmi_wx");

 #if wxCHECK_VERSION(2,9,0)

Here's my second attempt, which does behave as expected:

Index: skeleton.cpp
===================================================================
--- skeleton.cpp        (revision 5998)
+++ skeleton.cpp        (working copy)
@@ -630,6 +630,7 @@
             {
             return false;
             }
+wxLog::SetActiveTarget(new wxLogStderr);

         authenticate_system();

That's in OnInit(), right after ProcessCommandLine() is called.
(There, I can easily make it conditional on a command-line option,
although I tend to think that complication is unnecessary.)

Before I commit this, let me ask whether I'm missing anything;
but it seems good AFAIK.

It seems to have no effect on 'wx_test', which creates its own
wxLogWindow afterwards--thereby displacing wxLogStderr.

I've passed a 'new' pointer to wxLog::SetActiveTarget(), so it
seems reasonable to hope wx will 'delete' it at the right moment.

Almost all end users start lmi by double-clicking an msw "shortcut";
I didn't actually test this, but I believe they'll be unable to
perceive any change in behavior.