Most ASSERT macros (I'm assuming you're using some Microsoft version of them) are enabled in debug compilations and then nullified for release versions. In other words, an ASSERT macro might be defined like this: #ifdef _DEBUG #define ASSERT(expr) ...some assert code... #else #define ASSERT(expr) #endif Notice how the second ASSERT defition has nothing after it. That's because in non-debug builds, you don't want assertions to do anything. So, to possibly answer your question, you should probably dig up where your ASSERT is being defined and do #undef _DEBUG (to undefine debug build). Unfortunately, that turns off most debug features since many things test against _DEBUG being defined. Either do that, or compile as release, or create your own ASSERT macro based on other example code. HTH

Try this...in globaldefines.h, say #ifndef GlobalDefines_h #define GlobalDefines_h ...other code... extern const char* RPD_APP_FILE_EXT[]; ...other code... #endif And then in some other .cpp file (perhaps globaldefines.cpp), do the actual definition of RPD_APP_FILE_EXT, i.e. in the cpp file: #include "globaldefines.h" const char* RPD_APP_FILE_EXT[] = {".RPD", ".RVR", ".UDO", ".RDO", ".ZRP"}; ...other code... Even if you have include-guards on your headers, if they're included in multiple places and have variable definitions (not just declarations), then you'll usually get those link errors. HTH

I'm having all kinds of fun trying to iron out this problem, and im SURE there's an easy solution out there... I need to use COM interop between unmanaged C++ and VB .NET to have my C++ client catch and respond to events raised in VB .NET. More specifically, I've got a VB .NET custom user ActiveX control with a valid COM interface that I've imported and used in my C++ client. I can make function calls from the COM client to the .NET server, but I cannot seem to handle events from the control. I'm certainly no expert on COM interop, but I've browsed around and read bits of literature here and there on how to do this to no avail. The control doesn't seem to have any connection points to which I can connect to (which might be the problem), but trying to use ATL SINK_ENTRY with IDispEventImpl hasn't worked, nor has an MFC DECLARE_EVENTSINK_MAP with ON_EVENTs. I'm at a total loss and any help would be greatly appreciated. P.S. if none of this works, would it be feasible to pass VB a C++ function pointer via its COM interface and then have VB "call" the C++ function using this pointer? They're in the same address space so it should work, but can VB call a function given only an address as a long?

I'm having all kinds of fun trying to iron out this problem, and im SURE there's an easy solution out there... I need to use COM interop between unmanaged C++ and VB .NET to have my C++ client catch and respond to events raised in VB .NET. More specifically, I've got a VB .NET custom user ActiveX control with a valid COM interface that I've imported and used in my C++ client. I can make function calls from the COM client to the .NET server, but I cannot seem to handle events from the control. I'm certainly no expert on COM interop, but I've browsed around and read bits of literature here and there on how to do this to no avail. The control doesn't seem to have any connection points to which I can connect to (which might be the problem), but trying to use ATL SINK_ENTRY with IDispEventImpl hasn't worked, nor has an MFC DECLARE_EVENTSINK_MAP with ON_EVENTs. I'm at a total loss and any help would be greatly appreciated. P.S. if none of this works, would it be feasible to pass VB a C++ function pointer via its COM interface and then have VB "call" the C++ function using this pointer? They're in the same address space so it should work, but can VB call a function given only an address as a long?