2
votes

Using VB6, I have created an Outlook plugin, that has a property page. The property page is an OCX control.

When I compile the project to an OCX file, and then run OUTLOOK, things work fine: I am able to see my OCX as a tab in the Outlook options.

However, when I try to debug by running the OCX in VB6 I get an error. My debugging is started like this: 1) Debug options set to Wait for components to be created" 2) F5-RUN project in VB6. 3) Start Outlook. 4) Get the error: "Cannot display "MyOcx" page. This page will remain visible, but is not available. An OLE registration error occurred. The program is not correctly installed. Run Setup again for the program"

I suspect this is because, when debugging, the OCX is being created out-of-proc and Outlook doesn't like that.

Is there a good technique to use the VB6 debugger on the OCX in this scenario?

3

3 Answers

3
votes

The VB6 debugger is sometimes flaky when debugging DLLs or OCXs.

  • You could try Windbg, a free standalone debugger from Microsoft. Compile your VB6 OCX into native code with no optimisation and "create symbolic debug info" (i.e. create PDB files), and you will be able to debug your OCX in-process in Outlook. Here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft guy with a brief introduction to Windbg.
  • You could also use the Visual Studio 2008 debugger with VB6 and PDB files, e.g. with Visual C++ Express Edition (which is free). EDIT see Kris's answer for more details.
  • EDIT: Both Windbg and Visual Studio expect the source code to be in exactly the same path on the debug machine as it was on the build machine when the OCX was built. The easiest way is to build and debug on the same machine. Otherwise you might need to fiddle with SUBST to create virtual drives - or I'm told the serious way is to use a Symbol Server.
  • (Les serious) you could do without those newfangled interactive debuggers, just log to a file, or with DebugMessage calls from your VB6.
3
votes

The only way you are really going to be able to Debug this is In Process as MarkJ said. Using the free Visual Studio 2008 C++ Express Edition (or even better, Visual Studio 2008 Professional if you have it, and it is available for a 90 day trial) and a PDB.

To make sure you are creating the PDB, go into Visual Basic, check the P)roject / P)roperties and click on the Compile tag. Make sure "Create Symbolic Debug Info" is checked.

Next start up Outlook, and attach to that process from Visual Studio (T)ools / Attach To Process. Make sure your Ocx is shown in the modules window, and then load the PDB (right click on the Ocx in the modules window). You will probably have to add the source code in the Solution Properties (for more details on how to do that, read this post).

It's a bit of a pain in the butt the first time, but once you can do it, it becomes pretty easy, and is far easier than trying to determine what is going on from a log.

0
votes

I don't have much idea on the OCX.

However, you can use a tool which was part of visual studio named something like "activex control test tool".

As far as I know (based on my understanding of documentation), OCX is created in-proc.