How do I keep debugging output from trashing the graphics window?

[WSinc]

During when I develop a graphics application, the output from a PRINT
statement can cover up the graphics output. Also when the debug
output is near the bottom, it causes a scrolling of the graphics window,
which also trashes the graphics diagrams.

I was wondering if there's a way to isolate the PRINT statements from
whatever is drawn in a graphics window. For example, is there a special
logical unit that will put the DEBUG stuff in the startup parent window, and keep it
out of the graphics window?

Unfortunately, the PRINT statements are too valuable to comment out
during the debugging process. I would like to see those somewhere at least.
And it is sometimes necessary to provide prompts for the graphics input, i.e.
"Click mouse inside polygon" without interefering with the graphics output.

So, how do I isolate the two? Isn't the startup window a console one by default?

[Paul_Curtis]

The Windows GUI is all graphics, and anything that seems to resemble a text-mode console window which supports an ancient concept such as "PRINT" is entirely simulated, and the hidden text-mode simulation engine (Quickwin?) has no way of knowing that you have also used that window's device context for graphics, hence the unwanted scrolling behavior.

One way to address this is for your app to create separate windows for graphics and debugging output, each with their own handles and device contexts, and then use explicit scrolling and TextOut() for the debug messages. Or, at the very least, use TextOut() instead of PRINT so that the debug messages are all written to a fixed location which will not overwrite your graphics and will not scroll the window. TextOut() arguments include the device context (hDC), as well as x,y pixel locations within the window, plus the text itself, and this routine provides the improved output control that will solve your problem.

[WSinc]

Thanks for your reponse -

I was hoping there would be a less elaborate way to handle debugging output,
but it appears that will never be realized. Switching handles between debugging windows and
the actual graphics can create some really messy code. Perhaps just confining the debugging
to a small part of the screen would be more practical.

I'll look up Textout(). Maybe there is automatic way to convert the PRINT statements so
it isn't so painstaking.

May I suggest that we should have a special forum for graphics users?
It does seem rather specialized.

What do you guys think?

Yours; Bill S.

[Steven_L_Intel1]

The problem with debugging graphics is that the updates of the various windows are handled by threads in the application. When you pause in the debugger, all threads stop.

What I sometimes do is use message boxes to display debugging output.

As for another forum, this one is already split from Linux/Mac because of Windows UI questions. It will do.

[jimdempseyatthecove]

Assuming:

you have your application
application displays graphics in "DOS' window
application has statements to emit debug pertinant text information (currently to console window)
application has statements to emit operational text information pertinate to operation of application (currently console window)

You want to seperate debug info from other console window.


Suggestion:

create a named pipe
launch listener app reading from named pipe and writing to seperate console window
modify diagnostic emision to emit to pipe (with flush)

My IVF documentation is for V11

Search 'pipes'

pick: User-Supplied OPEN Procedures: USEROPEN Specifier

Use above example as template.
Merge with info obtained on pipes

search MSDN indexfor

pipes
named pipes

Jim Dempsey

[WSinc]

Thanks Jim -

I will try that. Certainly better than rewriting a lot of my existing code..

I had trouble finding your article. Do I need to have a subscription to MSDN
to reference it?

Yours; Bill

[jimdempseyatthecove]

Quoting billsincl

Thanks Jim -

I will try that. Certainly better than rewriting a lot of my existing code..

I had trouble finding your article. Do I need to have a subscription to MSDN
to reference it?

Yours; Bill

Start browsing at:

http://msdn.microsoft.com/en-us/library/aa365590(VS.85).aspx

Jim Dempsey

[jimdempseyatthecove]

I forgot to mention. If you use Google, search for:

named pipes site:msdn.microsoft.com

This will search for

named pipes

restricted to site: msdn.microsoft.com

Also try Google search for

CreateFile pipes site:msdn.microsoft.com

Jim

[Paul_Curtis]

You probably will not want to use pipes. See the att. file for details on how to use TextOut.