ActiveX control in a Excel file gives "Could not load an object..." error on some machines

Question

We are using a set of Excel files on several machines in our company. These files contain a VBA application which utilizes a couple of ActiveX control objects from mscomct2.ocx library (namely, MonthView and DateTimePicker). ActiveX objects are to be displayed in UserForm. Unfortunately the portability of these files seems limited in a very peculiar way.

There appears to be 2 groups of machines:

• Group A: I can create a Excel file containing MonthView on such machine and work with it on any Group A PC. But when I try to open this file on any machine from Group B, I'm getting a Could not load an object because it is not available on this machine error. However, files with the same ActiveX created on Group B machines work normaly on A machines.
• Group B: File with an ActiveX in question created on these machines work everywhere (i.e. on any A and B machine). But, as I said earlier, B machines give the error mentioned above when the file with ActiveX saved on A machine is opened.

In one sentence: files created on A machine work only on other A's, files created on B's work everywhere!

The strangest thing here is that every machine has mscomct2.ocx registered (once again: I can create the form with the MonthView on any machine in question!). The .ocx itself is in place on each machine and the whole set of registry keys is present (CLSIDs for controls classes, IIDs, typelib ID...). In addition, the data in these registry keys seem to be the same on A and B group machines (GUIDs, ProgIDs, versions etc.). There are slight differences in description strings (values like "Microsoft MonthView Control 6.0 (SP6)") on some machines but this does not seem to affect the situation (some machines in B group have such descriptions different but files created on them still work everywhere).

Naturally, thanks to Murphy's law, the machine I use to edit these Excel files belongs to Group A, so files saved here are 'unportable' to B machines...

The OS and Excel versions don't seem to affect the situation. For example, one of B machines is working under Win 7 64 bit (Excel 2007), while most others group A and B machines are Win XP Prof (32 bit) SP3, with Excel 2003 installed. So it seems that OS and Excel versions don't affect compatibility and the problem is somehow connected with ActiveX.

The only ActiveX-related difference between A and B groups I found is the file version of mscomct2.ocx: at least several of A machines have version 6.1.x.x, while Group B has 6.0.x.x. I don't see how can such difference cause problems (ActiveX are COM objects after all, and according to registry key values, the exposed typelib, com objects and interfaces seem to be the same in all cases). Nevertheless I tried to replace my 6.1.x.x ocx with 6.0.x.x version... and ran into more trouble. What I did is:

1. regsvr32 /u mscomct2.ocx - completed successfully
2. Replaced the mscomct2.ocx with file of 6.0.x.x version
3. regsvr32 mscomct2.ocx - completed successfully

After these steps I tried to make an Excel file with single form containing the MonthView. But when I tried to place a control in the form I've got a messagebox with error Class not registered. This is really strange cause everything seem to be registered: the control class, its interfaces, typelib (yes, I've checked the registry to be sure). But still the error was there.

After that I did the unregister/replace/register procedure again to go back to my original 6.1.x.x file. That took me back to the original SNAFU situation: I could again install ActiveX to user form and use it, but the Group B machines still gave the error on files saved by my machine.

I assume that the problem of files-with-ActiveX portability and the problem of ocx registration are somehow connected, but I don't see how. Perhaps there are some additional requirements for registration of an ActiveX in Excel VBA which I don't know...

The only thing I need is to have the ActiveX object contaned in my Excel file compatible with other machines. Can anyone help me with that?

Solution

I think one group (probably "A") has this installed: http://www.microsoft.com/download/en/details.aspx?id=10019, another one don't.