How to debug C++ OCX control in VS2010 hosted by VB6 ActiveX EXE

Question

I have an OCX control written in C++ and built with VS2010. The host application for the control is a VB6 ActiveX EXE. I am trying to figure out how to debug the OCX control in VS2010. Normally to debug an OCX control you put in the host application that embeds the control into the OCX control's Properties:Debugging:Command field. When I enter the VB6 Host program's EXE and try to start debugging it gives me the following alert box

I'm suspecting that the VB6 debug information is not compatible with VS2010. I don't actually need to debug the VB6 ActiveX EXE in this case. (I can do that from VB6 dev enviroment). But I've tried clicking yes to the above dialog and the OCX control runs outside the debugger as it ignores any breakpoints I've set. How do I get the OCX control to run under the debugger?

I've looked at this similar question but it seems a slightly different scenario as it sounds like all the OCX controls this case were in VB6. It talks about setting "Binary Compatibility" for the OCX control but I believe that only applies to VB6 environment and not to C++ under VS2010.

Also is there a way to generate debug info for VB6 ActiveX EXE that is compatible with VS2010 debug environment?

Answer 1

After some more exploration I found that it is possible to do what I initially asked in my original post.
While the VS2010 debugger doesn't automatically attach to the OCX control when started via the VB6 ActiveX EXE container, it is possible to attach to the OCX control manually. It is in fact possible to be running the container ActiveX EXE in VB6 debugger and simultaneously running the OCX control in VS2010 debugger. Here's the sequence

Start VB6 development environment with the ActiveX EXE project. Start execution of the ActiveX EXE in debug mode. Now start the VS2010 development environment and select menu item Debug:Attach to Process... and then select the VB6 process as the one to attach to. Now breakpoints in the VB6 app will route to the VB6 debugger and breakpoints in the OCX control will route to VS2010 debugger.

If you don't need to debug the VB6 ActiveX EXE you can specify it as the start Command for the VS2010 OCX control and then do the Attach to Process after it starts although using VB6 development environment insures that you can catch breakpoints in the OCX control at startup.