Member Avatar for GraveyDice

I have spent a few months upgrading a toolkit I created and is used extensively throughout our organisation of 2-3000 users. I used DTPicker controls as I found these were ideal.

My beloved organisation then upgraded to XP and decided that the standard desktop didn't need this control installed locally. My excel-based application no longer works.

I experimented with distributing the ocx file with the excel based application, and this worked for me. Problem is - it installs itself in the windows folder, and my beloved organisation prohibits almost all staff from writing to their hard drives.

So - I am left in a bit of a quandary. One line I am pursuing is registry setting changes that allows the ocx file to operate on a public drive and not self-install.

I have run searches on this and other forums (fora?) and not found anything that exactly matches what I am after.

Can anyone please advise me if there is a way to make mscomct2.ocx operate from a shared/public drive without self-installing to windows?


Many many thanks.


Gravey

  • 2 Contributors
  • 3 Replies
  • 206 Views
  • 10 Hours Discussion Span
  • Latest Post Latest Post by Comatose

Dani AI

Generated

Short expert summary and practical next steps for (and thanks to for the regsvr32 idea).

The Date & Time Picker in mscomct2.ocx is a COM/ActiveX control and Excel expects the control’s COM registration (ProgID/CLSID → InprocServer32) to be present on the client where the workbook runs. Using regsvr32 (or an installer) invokes the control’s self‑registration and writes those entries to the registry — that registration is what tells Excel where to load the OCX from. (learn.microsoft.com)

That’s why simply placing the OCX on a network/share with the workbook usually fails: COM activation reads HKEY_CLASSES_ROOT (the merged view of HKLM\Software\Classes and HKCU\Software\Classes) to find the InprocServer32 mapping. If the control isn’t registered machine‑wide (or the correct per‑user keys aren’t present for the running security context), Excel won’t find it. UAC/elevation makes per‑user tricks unpredictable. (learn.microsoft.com)

Practical options

  • Best/clean: ask IT to deploy and register the OCX for all users (MSI or a GPO startup/install script that copies the correct OCX (match Office bitness) into the system folder and registers it). That’s the reliable enterprise path. (learn.microsoft.com)
  • If IT won’t install: remove the dependency — replace the DTPicker with a pure‑VBA UserForm calendar or a data‑validation/date entry UX so you avoid ActiveX deployment entirely.
  • Advanced: registration‑free COM (manifest-based) or using an activation context from VBA can load an unregistered component for a single workbook, but it’s fiddly for ActiveX controls hosted on VBA UserForms and needs careful manifest/bitness handling; it’s an option only if you can invest time to test it. (learn.microsoft.com)

Quick checks before retrying:

  • Verify Office bitness: mscomct2 is a legacy 32‑bit VB6 control and won’t work with 64‑bit Office without changing approach. (learn.microsoft.com)
  • If a user reported “registry changes succeeded” but the control still failed, confirm whether the keys were written under HKLM (all users) or HKCU (per‑user) and whether Excel is running elevated — that mismatch explains many false “success” reports.

If you want, supply the Windows/Office bitness and whether users are domain-joined; I can list the exact registry keys that a working registration should create and the GPO‑script pattern IT can run.

Recommended Answers

All 3 Replies

Member Avatar for Comatose

I think if you store the ocx on a public drive, you can do a:

regsvr32 H:\Path\To\whatever.ocx

obviously H: would be the public drive. Have you tried putting on a public drive?

Member Avatar for GraveyDice

Yeah - I tried just having both the workbook and the ocx file in the same publick location, but it just kept trying to self-install. Mind you - I hadn't made the reg setting changes.

One of the dang problems is that I have rights different from the average user, so I can't really replicate what they do. I'm gonna try again to get the reg settings changed by the user, and see if that works.

I had seen the regsvr32 solution somewhere else, and tried it myself, and then tried to see what changes were made to the regedit settings, but couldn't find it.

I then created a batch file that just had the reg changes and got a user to try running that. They told me that they made the registry changes - the success message came up - but the problem didn't go away.

I don't much trust some of the users with doing things exactly right - or maybe I don't trust my instructions to be clear enough - so will see if I can grab a user's PC and do it myself.

It would, of course, help if my beloved employer would allow me remote administrator access so I can remote in to their PC and see what is happening.

Don't sound bitter, do I? :-)

Member Avatar for Comatose

Nah, Not at all :)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.