Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

TreeView ActiveX 2

Status
Not open for further replies.

florindaniel

Programmer
Dec 4, 2009
120
RO
Hi all,
It is, I think, obvious for you, but not for me... :(

I'm using a TreeView ActiveX control in one of my forms.
This control has not been used before and the app is already installed.
I understand there must be some OCX file; how do I know wich one?

1. What should I do next? Should I copy some files on the computers the app is running on?
Should I register something?

2. For a new computer, what should I do in Install Shield to cope with this problem?

Thank you
Daniel
 
Hi Daniel,

The file you need to distribute is MSCOMCTL.OCX. This file needs to be registered on the user's system. You can do that with REGSVR32.EXE. As far as InstallShield is concerned, you can just treat it like any other ActiveX control.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy
 
So, I need to copy MSCOMCTL.OCX on the destination computer and then Regsvr32 it.
OK, but can I include MSCOMCTL.OCX into my project and register it?
If I include the OCX into my EXE can I still register it (I mean : there's no OCX file any more) and in the long run: can I check if the OCX is registered and somehow register it from my app or there's no problem if I simply run some regsvr32 /s <some OCX file wich is included onto my EXE!> command each time I start the program ...

Btw... "just treat it like any other ActiveX control" [smile], I have only used standard controls until now so there's no "any other ActiveX" in my experience.

Thank you
 
You can't include an OCX or DLL or FLL inside a VFP exe, these stay a seperate files.

In many cases OCXes are depending on further files, eg C runtime or whatever language they are written in. In this case the OCX is the only file you need.

You better let Installshield handle the installation&registering, if not Inno Setup or something else.

In your installshield project the easiest to add an activex control installation is, you have the merge module (msm file) and just pick it from the list of the redistributables. It's mscomctl.MSM and listed as "Microsoft Windows Common Controls (6.0)".

You add it like you add the VFP Runtime Redistributable listed as "Microsoft Visual Foxpro 9 Runtime Libraries".

Indeed you can also add the OCX file and in the file list, right click on it and take a look at the properties. It has a tab "Com and .NET Properties" and there you can choose a Registration Type, either Extract COM information, which makes ISE extract the needed typelib information and put it in the registry at the setup process. With DLLs you can also choose Self-Register, as a COM DLL has to have a DllSelfRegister function inside.

The setup is the right place for registering as the setup by definition runs with elevated privileges and is able to register DLLs, OCXEs and also your own EXE, if it contains OLEPUBLIC (COM) classes. Registering from your Application at it'S runtime is possible very seldom since UAC (Vista and later) in cases the user does not start your exe via RunAs Admin. Even if you rely on most users running Windows as a user of the Administrator group, that will not enable them or your application to register an OCX.

If you fear the deinstallation or unregistering of MSCOMCTL.OCX put that away, you can't do much about it, as you can't prevent users from deleting things still needed or your whole applicaiton. You would catch Error 1434 and in case it happens inform the user, he needs to reinstall (or do a repair installation) to reinstall the missing OCX and register it.

Bye, Olaf.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top