Re: [lmi] PDF opening errors

[Vadim Zeitlin]

On Sun, 19 Oct 2014 19:00:15 +0000 Greg Chicares <address@hidden> wrote:

GC> Thanks. On another tangent...why was this message:
GC> 
GC> GC> > GC> In file ../src/msw/mimetype.cpp at line 272: 'AssocQueryString' 
failed with error 0x80070002 (the system cannot find the file specified.).
GC> 
GC> displayed only with 'wx_test.exe' and not with './lmi_wx_shared'?

 Simply because the debug messages are not displayed to the user in message
boxes by default, i.e. when using wxLogGui which is the default wxLog
target, but the test code sets up wxLogWindow log target to collect all
logs in a single place and wxLogWindow dose show all messages, including
the debug ones.


GC> Both use the same wx library, built the same way.

 I've just realized that this is actually a potential problem. While what I
wrote above is 100% correct, normally debug messages are not supposed to be
generated in the first place in the "release" or "production" builds. But,
as explained at http://docs.wxwidgets.org/trunk/overview_debugging.html, we
use NDEBUG symbol to determine whether we're building a production version
and LMI makefiles don't define NDEBUG (configure builds do define it
though, unless "--enable-debug" option is used). This means that
wxLogDebug() and wxASSERT() and related macros (wxFAIL, wxCHECK and all
their versions) remain active in LMI builds which may be not what you want,
i.e. I think that LMI should, at least optionally, suppress them because
they are normally not meant for the end users at all.


GC> The reason why I ask is that I'm wondering if there's some way I could
GC> (optionally) enable messages like this in the production system (say,
GC> only with a special command-line argument).

 Yes, the nice thing about wxWidgets 3.0 debug/release mode handling is
that it all happens during run-time: unless you went out of your way to
build wxWidgets without any debugging at all (i.e. configured it with
--disable-debug), the code of wxLogDebug() and assertion macros is always
compiled in and just remains dormant by default if NDEBUG is defined.

 As mentioned above, in LMI case it's not even dormant because, first,
NDEBUG is never defined and, second, because LMI doesn't use
wxIMPLEMENT_APP() which deactivates all this debugging stuff if NDEBUG is
defined (this is not part of IMPLEMENT_APP_NO_MAIN() used by LMI).

 The least intrusive way to do what you want would probably be to do this
deactivation ourselves in main_wx.cpp. If you decide to define NDEBUG, this
would be as simple as adding a call to wxDISABLE_DEBUG_SUPPORT(). If not,
you can still do it by manually doing what this macro does when NDEBUG is
defined, namely:

        wxDisableAsserts();
        wxLog::SetLogLevel(wxLOG_Info);


 Please let me know if you have any more questions and whether you'd like
me to make a patch doing the above. To be honest, I think it would be
simpler if you just addressed it yourself though, as the change itself is
trivial, the less obvious part is determining whether you want NDEBUG to be
defined or not (I think you should but you may think differently) and how
do you want to control wx debugging diagnostics (I think they should be off
by default and an option such as "--debug" should be provided to enable
them).

 Thanks,
VZ