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
}

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

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....

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.

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