[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] Using wxLogStderr [Was: NDEBUG]
From: |
Greg Chicares |
Subject: |
[lmi] Using wxLogStderr [Was: NDEBUG] |
Date: |
Sun, 26 Oct 2014 17:03:47 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
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.
- Re: [lmi] Manual test of automated GUI test, (continued)
- Re: [lmi] Manual test of automated GUI test, Vadim Zeitlin, 2014/10/18
- Re: [lmi] Manual test of automated GUI test, Greg Chicares, 2014/10/18
- Re: [lmi] PDF opening errors (was: Manual test of automated GUI test), Vadim Zeitlin, 2014/10/19
- Re: [lmi] PDF opening errors, Greg Chicares, 2014/10/19
- Re: [lmi] PDF opening errors, Vadim Zeitlin, 2014/10/19
- [lmi] NDEBUG [Was: PDF opening errors], Greg Chicares, 2014/10/23
- Re: [lmi] NDEBUG, Vadim Zeitlin, 2014/10/23
- Re: [lmi] NDEBUG [Was: PDF opening errors], Greg Chicares, 2014/10/23
- Re: [lmi] NDEBUG, Vadim Zeitlin, 2014/10/24
- Re: [lmi] NDEBUG, Greg Chicares, 2014/10/26
- [lmi] Using wxLogStderr [Was: NDEBUG],
Greg Chicares <=
- Re: [lmi] NDEBUG, Vadim Zeitlin, 2014/10/26
- Re: [lmi] NDEBUG, Greg Chicares, 2014/10/26
- Re: [lmi] NDEBUG, Vadim Zeitlin, 2014/10/27
- Re: [lmi] NDEBUG, Greg Chicares, 2014/10/29
Re: [lmi] Manual test of automated GUI test, Vadim Zeitlin, 2014/10/18