Click-to-run deployment does not include MSCOMCT2.OCX

Question

Hi all,

I'm struggling to support the (by now) two customers who are running VBA macros in Microsoft Project in an enterprise environment, i.e. Project Server or Project Online is also used. Parts of their solution stopped working, and it looks like the reason is Click-to-Run where they previously used an MSI-based setup and a volume license activation.

I would like to point out, before people start shouting at me, that this affects *all* Office products on the machines in question. The missing controls are also missing in Excel, Word, PowerPoint, and Outlook, as far as we have checked. So Project may serve as an example here but it's a rather general issue.

The VBA macros are in the Enterprise-Global project and downloaded to the Project clients when they connect to the respective enterprise profile. The macros contain dialogs using the DatePicker ActiveX control which is part of the Microsoft Windows Common Controls 2 library.

As it seems, clients who got their copy of Project used an MSI setup can use the macros without any issues and with all features whereas those users who have acquired Office via a Click-to-run deployment can't. They are getting error messages as soon as the Enterprise-Global loads, announcing that there is a control that isn't available. It's really that general, there is no mention of the control that's missing, nor the place where it is missed. The same message appears again when the forms designer in VBA is used to show the dialog in question. What remains is a dialog that no longer contains the DatePicker, there is just blank space where it used to be, and of course the code will no longer compile nor run. That's only on the Click-to-run machines though. MSI-based consumers of the *same* macros from the *same* Enterprise-Global have no trouble at all. But it's mixed environments unfortunately, and I have no way to change that. It's administrative policy.

Listing the available ActiveX controls in the Click-to-run Project VBA reveals that the components from the Microsoft Windows Common Controls library are readily available whereas the extension library having the 2 in its ending is missing. Clicking said library will claim that it is installed in C:\Windows\System32\MSCOMCTL.OCX but that just isn't true. It's what the dialog thinks because it is not aware of being virtualized (wild guess).

The MSCOMCT2.OCX is well available in C:\Windows\System32 and its controls (as well as those from MSCOMCT2.OCX) are also registered properly outside the virtualized world.

So if I'm understanding it correctly. Click-to-run means the Office products are partially using their own virtualized system (including their own isolated registry) and components instead of those belonging to the host's Windows installation. We then navigated a file explorer to C:\Program Files\Microsoft Office\root\vfs\System and bang, there it is. MSCOMCTL.OCX exists there but MSCOMCT2.OCX doesn't!

As ActiveX controls need to be registered, but there seems no way to use regsvr32 to register something "into" the virtualized realm, it wouldn't help to copy MSCOMCT2.OCX from the System32 folder to the virtualized one. Starting regedit, or anything else, from a shell launched in VBA (from a virtualized app) will not return a shell that lives "inside" the virtualization so that also didn't work.

So the questions are:

• why was MSCOMCT2.OCX forgotten, or not included, in the Click-to-run deployment?
• what's the recommendation in this case if we have logic that depends on the missing control(s)?
• or better, if there's a way, how do we get it working? (besides replacing the previous DatePicker by a plain old text box)

I couldn't find anything about this specific behavior in the web. There is not exactly a vast amount of information on ActiveX controls in Click-to-run virtualized Office products so I feel like I'm the first to notice this issue.

Hope anyone here can help.

Thanks a ton people!

Cheers,

Johannes

Answer 1

Regarding your questions, MSCOMCT2.OCX is not included in Click-to-Run deployment because it is not a part of the core Office products. It is a part of the Microsoft Windows Common Controls 2 library, which is not included in Click-to-Run deployment.

As for recommendations, you can try using alternative controls that are included in the Click-to-Run deployment, or you can try using a different deployment method that includes the necessary components.

Unfortunately, there is no way to register something "into" the virtualized realm, so copying MSCOMCT2.OCX from the System32 folder to the virtualized one will not work.