terence@ttidca.TTI.COM (Terence Davis) (11/08/90)
Distribution: Organization: Citicorp/TTI, Santa Monica Keywords: printf It is possible to use printf() in PM programs if you can live with seeing the output after program execution. I discovered that if I run the PM program in a cmd.exe window inside my editor (Epsilon) I will see the printf'ed strings when I exit the PM program. This is not so good for following the execution trail of a program while it's running, but if you want to see the values of variables it works great. Terry
lsalomo@hubcap.clemson.edu (lsalomo) (11/08/90)
Another good way to trace your program is to write some code containing the following procedures: TrcStart(HWND hwnd); TrcStop(HWND hwnd); TrcWrite(HWND hwnd,PCHAR fmt,...); TrcStart checks a list of active trace windows, and creates a NEW window containing a listbox if the window handle does not already have a trace window associated with it. TrcStop checks the list of active trace windows, and WinDestroyWindow()s the trace window associated with the specified window handle. TrcWrite uses vsprintf() to format the string and sends a LM_INSERTITEM to the trace window's listbox to write the string out. If you create your listbox with LS_HORZSCROLL, then you have a full-fledged tracer that can be used with any PM program. Cheers, Q - the "Q"uestor for knowledge (, a degree, etc.) lsalomo@hubcap.clemson.edu ibmman@clemson.clemson.edu ============================================================================= "Gee Wally, I think there's something wrong with the Beaver." =============================================================================
duncanb@ibmpcug.co.uk (D G Booth) (11/09/90)
In article <21079@ttidca.TTI.COM> terence@ttidca.TTI.COM (Terence Davis) writes: > It is possible to use printf() in PM programs if you can live with seeing > the output after program execution. I have a device driver that gives a device called AUX which is actually my mono monitor. I frequently run PM programs redirected to AUX so that I can see the debugging printf's as they come out. The only thing you have to watch with this is that the C runtime library will attempt to buffer output, so it is worth overriding this with setbuf. I believe the device driver is reasonably widely available. Duncan Booth -- Automatic Disclaimer: The views expressed above are those of the author alone and may not represent the views of the IBM PC User Group. -- Duncan Booth, RCP Ltd. Didcot, Oxon, UK duncanb@ibmpcug.co.uk Bix: jrichards
db3l@ibm.com (David Bolen) (11/10/90)
In article <21079@ttidca.TTI.COM> terence@ttidca.TTI.COM (Terence Davis) writes: >It is possible to use printf() in PM programs if you can live with seeing >the output after program execution. I discovered that if I run the PM >program in a cmd.exe window inside my editor (Epsilon) I will see the >printf'ed strings when I exit the PM program. This is not so good for >following the execution trail of a program while it's running, but if >you want to see the values of variables it works great. Actually, you do see the output while the program runs, but subject to whatever buffering the C library is performing on the standard output screen. This works because Epsilon runs concurrent processes in their own full-screen session, which it has VioRegistered to get all the Vio calls for. Normally, stdout for a PM program is discarded rather than showing up in any window, but since Epsilon is handling the output requests it can catch them and put them in its buffer anyway. I've used this a lot in my PM programming (I'm a big fan of printf-debugging) and found it invaluable. Try adding some fflush(stdout) calls after your printfs and/or issue a setbuf() call on the stdout file with a NULL pointer to disable buffering, and you should see your output as your program runs. Of course, if you can live with output following a program's execution, you can always use printf and just redirect the output of the program to a file, then look at the file later. This does run into problems though if your program TRAPs since not everything may be flushed to the file (especially if C buffering was involved). -- David Bolen -- /-----------------------------------------------------------------------\ \ David Bolen / | Laboratory Automation, IBM Thomas J. Watson Research Center | / P.O. Box 218, Yorktown Heights, NY 10598 \ | - - - - - - - - - - - - M i t h r a n d i r - - - - - - - - - - - - | | Internet : db3l@ibm.com | Bitnet : db3l@yktvmv | | Usenet : uunet!bywater!arnor!larios!db3l | Phone : (914) 945-1940 | \-----------------------------------------------------------------------/