• Andy C (52/54) Aug 06 2007 I have given up trying to use any debugger with DMC. Too many
• Arjan (5/8) Sep 02 2007 What do you mean? You gave up debugging with the DMC debugger? Or did
• Andy C (6/6) Sep 10 2007 I don't have the msvc debugger. I tried windbg, the DM debugger,
• Andy C (9/9) Sep 11 2007 Let me clarify my problem, there are a number of cases where I am
• Nicholas Jordan (7/7) Dec 14 2008 This is common problem, debuggers are clumsy to use and prone to

Andy C <noone noname.com> writes:

I have given up trying to use any debugger with DMC.  Too many
changes have rendered all of them either incompatable or unstable
(thanks Bill).  From now on I will compile in release mode, replace
all references to TRACE() with my new function TraceEx() and when I
want output I will compile the version by defining _TRACEEX and
then run DebugView.exe before I run the program.  Not as good as a
debugger but at least I can trace the execution, and it does give
me the ability to revert to TRACE() if needed.

=======================================================

bool m_bTraceExEnabled = true;

/**
 * New Trace function, replaces TRACE.
 * This gives 2 modes of operation, Off or OutputDebugString().
 * This allows the use of trace lines with release code.
 */
void TraceEx(LPCTSTR lpszFormat, ...)
{
	#ifdef _TRACEEX	// Use TraceEx code
		if (!m_bTraceExEnabled)
			return;

		va_list args;
		va_start(args, lpszFormat);

		int nBuf;
		TCHAR szBuffer[1024];

		nBuf = _vstprintf(szBuffer, lpszFormat, args);
		ASSERT(nBuf < _countof(szBuffer));

	//		if ((afxTraceFlags & traceMultiApp) &&
(AfxGetApp() != NULL))
	//			afxDump << AfxGetApp()-
m_pszExeName << ": ";

	//		afxDump << szBuffer;
		OutputDebugString(szBuffer);

		va_end(args);
	#else // Use TRACE
		#ifdef _DEBUG // all AfxTrace output is controlled
by afxTraceEnabled
			if (!afxTraceEnabled)
				return;

			va_list args;
			va_start(args, lpszFormat);

			int nBuf;
			TCHAR szBuffer[1024];

			nBuf = _vstprintf(szBuffer, lpszFormat,
args);
			ASSERT(nBuf < 1020);

			if ((afxTraceFlags & traceMultiApp) &&
(AfxGetApp() != NULL))
				afxDump << AfxGetApp()-
m_pszExeName << ": ";

			afxDump << szBuffer;

			va_end(args);
		#endif
	#endif
}

Arjan <arjan ask.me> writes:

Andy C wrote:
 I have given up trying to use any debugger with DMC.  Too many
 changes have rendered all of them either incompatable or unstable
 (thanks Bill).

What do you mean? You gave up debugging with the DMC debugger? Or did 
you mean to give up on the debugging altogether?

fwiw it is possible to use the msvc debugger with dmc.

Arjan

Andy C <sdf ha.com> writes:

I don't have the msvc debugger.  I tried windbg, the DM debugger,
and watcom.  There are too many examples where I add a library that
runs fine in release, but hangs in debug under a debugger.  It is
just too difficult to figure out.  This does not always happen, and
it is not MD's fault, but happens often enough and until I have
more time....

Andy C <no no.com> writes:

Let me clarify my problem, there are a number of cases where I am
using libraries or DLL's where the code runs fine, but when run in
a debugger will crash the program.  The most current problem is
with a firewire camera driver from QImaging (the DLL requires .Net
so that may be a contributor) that produces a "protection Fault"
when loading the driver.  Either build version of code works fine
outside the debugger but both crash under any debugger (watcom,
windbg, or DM) so it is not DM's fault.  Putting the call in a try-
catch block does not help.

Nicholas Jordan <ab5_041 inbox.com> writes:

This is common problem, debuggers are clumsy to use and prone to
being taken over by system utilities. If I may suggest writing to a
file during prototyping. It is still clumsy to remove all the print
(test_value) but that can be overcome using boolean debug = true /
false early in the file. Then you do if(debug){print to log;}, the
compiler will remove these from the code path - see Effective C++
in the Addison-Wesley Professional Series