Windows Installer rears its ugly head 2

[Mike Lewis]

I have just been at a client's office, where I installed the latest copy of my executable.

As usual, everything worked OK, except that when I tried to open certain forms, the Windows Installer popped up, complained that a component from Office 2000 Professional was missing, and prompted to insert the Office setup CD.

There is nothing in my application that uses any Office components in any way, and I have not seen this prompt when running my app on other PCs. The only thing the forms in question have in common is that they all use the Microsoft Treeview control (but other forms in the app also use that control, and don't show the same problem).

If I cancelled the Installer prompt, everything worked OK - until the next time I opened the form, at which point the prompt came back.

I finally succumbed to the request, inserted the Office CD, after which all was well.

This was a nuisance rather than a disaster, but I'm curious to know why it happened and how to avoid it in future. Has anyone else come across this behaviour?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[DougHennig]

Hi Mike.

This problem is caused because of something Windows Installer does to the Registry entry for ActiveX controls: it changes the InprocServer32 entry to point to Windows Installer rather than the OCX file. When you install your application after Office (or vice versa) and run it, Windows calls the InprocServer32 entry when it instantiates the ActiveX control, which calls Windows Installer, which sees that the version of the OCX you've installed is different than what was originally installed, so it thinks the file is corrupted and prompts you to insert the CD so it can "repair" it.

The solution is to hack the Registry and change the InprocServer32 entry to the path and filename for the OCX. That way, it'll call the OCX rather than Windows Installer. In this case, the key is HKEY_CLASSES_ROOT\CLSID\{C74190B6-8589-11D1-B16A-00C0F0283628}\InprocServer32 and the filename is C:\Windows\System32\MSComCtl.OCX.

Doug

 

[Mike Lewis]

Doug,

Thanks for that very clear explanation. I'll keep a note of your solution and try it next time the problem comes up.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[hjohnson]

One additional (hopefully related) question here, If not I should probably start a new thread.

Does this apply to registering of all OCXs, or just a few. I've just added to our application the use MSCOMM32.ocx which is intended to read the weight from a scale. In development it worked perfectly and when set up the clients server (vfp9 is installed), also worked perfectly, but doesn't work on an of the workstations. Users seem to be unable to CREATEOBJECT("MSCOMMLib.MSComm")

We've manually registered mscomm32.ocx and comcat.dll (which according to the mscomm32.dep is a dependency) and still are unable to communicate with the scale.

Could the registry hack over some solution here?

thanks-
Hal