Reuse wxMessageOutputStderr for wxLogStderr implementation.

In addition to avoiding (tiny) code duplication, this ensures that both places
use the stream in the same orientation, i.e. either both use the narrow
functions or the wide ones. Thus, it fixes a problem with output simply
disappearing if wxLogStderr and wxMessageOutputStderr were both used: the one
used first disabled any output by the other one.

Closes #14782.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74427 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

diff --git a/src/common/log.cpp b/src/common/log.cpp
index 53ce213b5080316dacd55dd3efffa6ccd398a56a..376a93365b7f00e4865a08d869501ba90a713d8b 100644 (file)
--- a/src/common/log.cpp
+++ b/src/common/log.cpp
@@ -856,8 +856,10 @@ wxLogStderr::wxLogStderr(FILE *fp)
 
 void wxLogStderr::DoLogText(const wxString& msg)
 {
 
 void wxLogStderr::DoLogText(const wxString& msg)
 {

-    wxFputs(msg + '\n', m_fp);
-    fflush(m_fp);
+    // First send it to stderr, even if we don't have it (e.g. in a Windows GUI
+    // application under) it's not a problem to try to use it and it's easier
+    // than determining whether we do have it or not.
+    wxMessageOutputStderr(m_fp).Output(msg);

 
     // under GUI systems such as Windows or Mac, programs usually don't have
     // stderr at all, so show the messages also somewhere else, typically in
 
     // under GUI systems such as Windows or Mac, programs usually don't have
     // stderr at all, so show the messages also somewhere else, typically in