>>>
>>>Expanding on my previous reply: would it be possilbe to rename ComCtl and install the renamed component?. I use only the TreeView control because I can not avoid it but it's given me lots of problems over the years. If I could be sure that the ocx is always the same regardless of versions and software installed I would be much happier.
>>
>>Renaming the file won't help; the ProgID of the ActiveX control is the issue, no matter where you put the file or what you name it, the ProgID reference is the issue.
>
>One can always hope. I thought it was too easy. How to deal with ocx versions? It's happened before, that something has overwritten one of the components in one app bringing it to a halt.

In my case, I avoid adding the control visually, and instead use the form's or page's AddObject method to add the ActiveX control at runtime. This avoids many of the problems encountered with VFP forms when controls change.

By using the ProgID to reference the control, I get out of the version update war. When multiple versions of a control are present, the rule for which one is selected is 'last man standing wins'. IOW, whatever version of the control was last registered is the one that gets loaded, and as a result, if the name of the ActiveX control's OCX changes, or one in a different directory is referenced, I've got no hard-coded file reference in my form to deal with, and I don't have to contend with problems from early binding by the form. Early binding resolves the VTABLE (a reference table of methods, collections and properties) at compile time, speeding up the initial loading of the control and reference of method and properties, at the cost of being tied very tightly to a specific version of the control. Late binding uses runtime resolution of the references, which while somewhat slower, is much more version-independent.

This keeps me from getting caught up in the rat race of 'version, version, which one's the version I understand?' If the ActiveX control vendor is careful to make the new control implements a superset of the old control's functionality, then as long as the new one supports the functionality that the old one had, I don't care that a newer version is installed later, and I make sure that my own installs are well-behaved, checking the version and date/time stamp of the current file before putting a theoretically newer one in place. it avoids getting burned when a newer version of the control may have been released with another product.

It's an unfortunate fact of life, but a developer needs to know more about things like ActiveX and OLE Automation than 'just drop it on a form and use it!'