Hi,

If mscomctl.ocx is modified,then will it have any problem in installing ActiveX related components?If so,how to fix it?
I have seen a package which modifies mscomctl.ocx at the time of installation,where as the actual setup.exe wont modify.Will this be the reason for the application's inability to install ActiveX related components?

Pls reply...

Thanks
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
MSCOMCTL.OCX is itself an ActiveX control (as the name suggests, it deal with a set of COMmon ConTroLs) and doesn't affect whether or not other ActiveX controls can be installed or not.

To be a total pedant, it would most unlikely that a deployment would modify the file: it would replace it. 'Modify' implies a patching process of some kind.
Answered 08/04/2010 by: VBScab
Red Belt

Please log in to comment
0
This application actually needs client side server connectivity,and we are not able to replicate the error here at our side.What difference we found between setup.exe and package is only this ocx is getting modified, as per Installrite,and the application is showing ERROR:429 when shortcut is launched.(Error Description : ActiveX component cannot create object).

Will it be better if we register the ocx and then add it to package?

Thanks...
Answered 08/04/2010 by: win7packager
Senior Yellow Belt

Please log in to comment
0
InstallRite is showing it as modified because, in all likelihood, the version info has changed as well as the date and time stamp. It will have been replaced.

No offence, but I suggest you change your moniker here at AppDeploy because, if you don't understand ActiveX - and you clearly don't - you cannot reasonably call yourself a packager. That is further evidenced by your thinking that registering the OCX on your packaging machine before adding it to a package somehow means that its COM information will get added to the client machine.

Most packaging tools will read COM information from a DLL/OCX and add it to the appropriate MSI tables without the packager's intervention. Failing that, most will have a utility (e.g. WiseComCapture in Wise) to extract that information to a .REG file. On importing that file, the tool will again populate the relevant tables.

Can I suggest you get hold of Phil Wilson's ouevre, The Definitive Guide to Windows Installer? That will give you a good grounding in WI fundamentals. Then you can start packaging.
Answered 08/04/2010 by: VBScab
Red Belt

Please log in to comment
0
Try with Gap Capture if you can find some relevant info which is useful :)
Answered 08/04/2010 by: mekaywe
Brown Belt

Please log in to comment
Answer this question or Comment on this question for clarity