View Full Version : register ocx files

06-21-2006, 04:35 PM
I have a custom action that runs msiexec /y to register an .ocx file. I have set this custom action to run deffered and I reference the location of the .ocx file via a property.
Now that the architcture is different in InstallShield 12 am I to handle this with CustomActionData too???

Christopher Painter
06-21-2006, 07:28 PM
Yes, but the real question is why are you doing Self-Registration in a custom action? This is what the COM tables are for.

But if you must..... create a Type51 and set it to the fully formatted path to the OCX ( [INSTALLDIR]Foo.ocx ) and then in your EXE custom action pass /y [CUSTOMACTIONDATA] as the args.

06-22-2006, 10:19 AM
The actual .ocx file I need to register is not part of the installation. It is referrencing a file that is on a server where the user runs the installation from.

Christopher Painter
06-22-2006, 11:25 AM
I figured that was the most likely scenario.

So what happens if that file doesn't exist? Is it a prereq and you abort via LaunchConditions or will your product fail? Should that OCX actually be a component in your install and registered through the COM tables?

06-22-2006, 11:31 AM
The custom action only runs if the ocx is found on the server machine.
Looking at the log file, CustomActionData has the correct location and file name to the ocx file. But when I look through my ActiveX utility, the control is not listed.

Christopher Painter
06-22-2006, 11:33 AM
It might be helpful to create an InstallScript custom action and do the registration there. This allows you to pass different types of data to the CA, invoke the debugger ( hotfix required for deffered CA's as mentioned in another thread here ) and handle error catching better.

06-22-2006, 11:37 AM
But this was never a problem since the installation was created (IS Dev 7). It's only a problem now with IS 12. There's gotta be some sort of reasonable workaround right?

Christopher Painter
06-22-2006, 11:57 AM
When you say you have a custom action, what kind is it exactly?

06-22-2006, 11:59 AM
With IS 10.5 the custom action type was 1122. Since I had to use CustomActionData in IS 12, the custom action type is now 3170

Christopher Painter
06-22-2006, 12:12 PM
Ok, the reason your Type # changed is InstallShield added the msidbCustomActionTypeNoImpersonate flag for you!

That's a good thing! :)


This is to make sure that when a non-privileged user is performing an elevated installation of an advertised package that your CA will run with SYSTEM privs instead of user privs. In the case of Registering an OCX this is very much needed.

The refactoring of InstallScript has nothing to do with this and your old implementation should still be working. I need more details on your CA TARGET to see whats going on though.

06-22-2006, 12:24 PM
Ok, here is what's in my custom action table verbatim:
IS 10 version:
Action = caRegSprOcx
Type = 1122
Source = SystemFolder
Target = msiexec /y "[SPROCXLOC]"
In Exec Sequence after PublicProduct

IS 12 version:
Action = caRegSprOcx
Type = 3170
Source = SystemFolder
Target = msiexec /y "[CustomActionData]"
In Exec Sequence after PublicProduct

Action = caSetCADforSPROCXLOC
Type = 51
Source = caRegSprOcx
Target = [SPROCXLOC]
In Exec Sequence after InstallInitialize