Open tksoh opened 3 years ago
It is technically "expected", but not necessarily desirable.
Basically, Windows apps can be either console or graphical, and a graphical app doesn't have its stdout/stderr/stdin connected to the terminal which launched it.
This is fixable though :-)
It's actually something I've looked into before and found a solution for eventually!
https://stackoverflow.com/questions/311955/redirecting-cout-to-a-console-in-windows
Glad you know you already looked into this before. I wonder how Qt Creator is able to capture the messages. Perhaps it's not really running the same exe we run on cmd.exe?
In any case, this printing to console approach is never the right one to me from the get-go (hence this 15-year-old SF patch), as it's impractical to have to keep track of which terminal nedit will be printing the messages. We should really add a log window to display the messages, which would seem like to pretty easy hack for you ;-)
Oh, well I assume that Qt Creator doesn't use cmd.exe
at all and just launches it with CreateProcessEx
. Then it can redirect the stdout/stderr of the process to where it pleases, including it's own debug output pane
And yes, we can do something similar and create a fancy log window :-). That's definitely in the plan. Just a matter of figuring out minor aesthetics of it.
I've been using t_print() to print debug messages from my macros without issue when running NG release build from within Qt Creator, where the output of t_print() are captured in the Application Output tab. Running NG from terminal on Linux has been working well too.
However, when I ran the same release build from cmd.exe or Powershell on Windows 10, I don't get any output from t_print() at all.
Is this expected?
Using commit b43c9af2624ff832e774b266b37393120db17029