Re[2]: [lmi] Catching exceptions thrown in OnInit()

[Vadim Zeitlin]

On Wed, 28 Jun 2006 19:00:26 +0000 Greg Chicares <address@hidden> wrote:

GC> Let me quote my whole implementation and its inline documentation,
GC> below, to explain why I'm doing this. Perhaps you'll find a flaw in
GC> my reasoning, though I do believe I tested everything carefully
GC> before writing the comment. Or perhaps you'll tell me that wx's own
GC> ::wxSafeShowMessage() is now perfectly equivalent to this

 It looks like it isn't but I believe it should be changed/fixed as
necessary because it is supposed to do exactly what safe_message_alert()
does.

GC> /// The msw implementation of wxSafeShowMessage() uses ::MessageBox()
GC> /// with a null parent, which adds an undesirable extra "task" to the
GC> /// alt-Tab order, yet doesn't disable the application's top window.
GC> ///
GC> /// If MB_TASKMODAL is specified, then the extra "task" is still
GC> /// added, but all of the application's top windows are disabled.
GC> /// Unfortunately, MB_TASKMODAL is in effect ignored unless the parent
GC> /// is null.
GC> ///
GC> /// If the main top window (the one returned by wxApp::GetTopWindow())
GC> /// is used as the messagebox's parent, then the extra "task" is not
GC> /// added, but only the parent is disabled. Any other top windows the
GC> /// application may have are not disabled.
GC> ///
GC> /// The extra "task" seeming to be the worse evil, this implementation
GC> /// specifies a non-null parent wherever possible. MB_TASKMODAL is
GC> /// nevertheless specified as well, though its beneficial effect is
GC> /// realized only if no parent can be found.

 I'm not sure I understand the logic here: why is the extra task so evil? I
believe the possibility to do something (potentially catastrophic) in a
non-disabled window while the program is in an unstable state is a much
worse evil. IOW, I think wxSafeShowMessage() should continue to use NULL as
parent window argument but should also use MB_TASKMODAL.

GC> void safe_message_alert(char const* message)
GC> {
GC> #if !defined LMI_MSW
GC>     std::fputs(message, stderr);
GC>     std::fputc('\n', stderr);
GC>     // Flush explicitly. C99 7.19.3/7 says only that stderr is
GC>     // "not fully buffered", not that it is 'unbuffered'. See:
GC>     //   http://sourceforge.net/mailarchive/message.php?msg_id=10388832
GC>     //   http://sourceforge.net/mailarchive/message.php?msg_id=10826040
GC>     std::fflush(stderr);
GC> #else  // defined LMI_MSW

 Interesting. I can't access these links right now ("We're Sorry. The
SourceForge.net Website is currently down for maintenance. We will be back
shortly") but I thought that "not fully buffered" means either "unbuffered"
or "line buffered" (i.e. flushed on newline) so this fflush() seems to be
unnecessary. OTOH it surely does no harm.

 Regards,
VZ