I wonder if there is some way to speed up the debug output in LabWindows.
When a program is debugged in LabWindows all the debug output is routed to the Debug Window, so we see strings from our own DebugPrintf() statements, and strings from OutputDebugString() from any other DLL linked by our process.
This string output is SLOW, and the slow down affects even separate threads in our experience.
For example, I have here a program with several threads that manage CAN networking.
As soon as I open, in the UI thread, a FileSelectPopupEx the underlying comdlg32.dll starts to emit a lot of debug messages (Win 10 pro 1709) and all communication background fails in unpredictable ways.
This could be helpful if my intention was to develop some time independent handshake, but this isn't the case.
The text rows in the debug window appears slowly, as they come from a serial terminal of past age, and I can't believe this is the best it can be done to show those messages: for sure it's missing some queuing - or whatever buffering - between process and debugger.
As preventive measure, I've routed all my own debug messages to a custom XDebugPrinf() that sends messages via UDP to the simplest server you can imagine, but this of course does not work for system DLLs.
I'm stuck in nondebuggable code sections, and for the first time in past years I'm facing something I cannot workaround.
Very frustrating.
If only I could tell CVI "please ignore OutputDebugString"...