Debug compile causes AutoCAD 2004 run time error

Debug compile causes AutoCAD 2004 run time error

Anonymous
Not applicable
541 Views
2 Replies
Message 1 of 3

Debug compile causes AutoCAD 2004 run time error

Anonymous
Not applicable
Hi folks,

Apologies if this is a newbie question, I've just inherited a
substantial AutoCAD ARX application and I'm new to ARX programming (lots
of useless MicroStation MDL experience though...). I've read through the
ObjectARX docs as well as this newsgroup and haven't seen the same
problem nor had any meaningful Google hits on it.

Anyways, the application I am trying to compile seems to work fine in a
Release compile, but on a debug compile I get an Assertion Failure
window popping up from ACAD.EXE.

In the command history I get the following message:

"Warning: [APPNAME].arx allocates memory from MSVCR70D.DLL, but AutoCAD
uses memory from MSVCR70.DLL.
This may cause problems."

Clicking produces this error:
"[APPNAME].arx is an invalid ARX file."

This occurs as soon as I load the ARX, not when starting the debugger
necessarily.

The application links in several other 3rd party LIB files, but I have
recompiled these as Multi-threaded release LIBs, so I'm not sure why it
is still linking in the debug versions. Do you typically have to
manually exclude the debug LIBs to compile in DEBUG mode?

Is it possible to link to the DEBUG versions of the standard link
libraries? Do the link options for DEBUG have to be substantially
different to the RELEASE options?

Apparently the previous programmer never got the application to compile
in DEBUG mode, so he put a lot of debugging info into an external file.
I'd much rather use the VS debugger interactively if this is possible,
and it certainly seems everyone else here is using the VS debugger
successfully.

Anyone got any ideas?

For the record, I'm compiling using MSVS 2002 .NET with Object ARX 2004
on Windows XP Pro on AutoCAD 2004.

Cheers.



--

Piers Porter
Corporate Montage
http://www.corporatemontage.com.au
0 Likes
542 Views
2 Replies
Replies (2)
Message 2 of 3

Anonymous
Not applicable
Does your stdafx.h header have the '_DEBUG workaround'?

// 'DEBUG workaround' below prevents the MFC or ATL #include-s
// from pulling in "afx.h" that would force the debug CRT through
// #pragma-s.
#if defined _DEBUG
#define _DEBUG_WAS_DEFINED
#undef _DEBUG
#pragma message (" Compiling MFC header files in release mode.")
#endif

...standard MFC/CRT/ATL includes...

#ifdef _DEBUG_WAS_DEFINED
#define _DEBUG
#undef _DEBUG_WAS_DEFINED
#endif

Also remove any includes to MFC/CRT/ATL headers from any other .cpp
files and move them to your stdafx.h header

--
Best regards,

Byron Blattel
CADwerx--Applications for AutoCAD
Autodesk Registered Developer
Contact Info @ http://www.cadwerx.net
Custom Programming Services - ObjectARX/C++/MFC/ASP/STL/ATL/ISAPI...
0 Likes
Message 3 of 3

Anonymous
Not applicable
Hi Byron,

Thanks for that. I had tried the _DEBUG workaround, but I hadn't applied
it to the #included by one of the libraries that was linked
in. Putting it in all my headers seems to have done the trick.

Thanks for that.

- Piers.


Byron Blattel wrote:
> Does your stdafx.h header have the '_DEBUG workaround'?
>
> // 'DEBUG workaround' below prevents the MFC or ATL #include-s
> // from pulling in "afx.h" that would force the debug CRT through
> // #pragma-s.
> #if defined _DEBUG
> #define _DEBUG_WAS_DEFINED
> #undef _DEBUG
> #pragma message (" Compiling MFC header files in release mode.")
> #endif
>
> ....standard MFC/CRT/ATL includes...
>
> #ifdef _DEBUG_WAS_DEFINED
> #define _DEBUG
> #undef _DEBUG_WAS_DEFINED
> #endif
>
> Also remove any includes to MFC/CRT/ATL headers from any other .cpp
> files and move them to your stdafx.h header
>


--

Piers Porter
Corporate Montage
http://www.corporatemontage.com.au
0 Likes