>>In a VFP5 app, I have 3 MS ActiveX controls - TreeView, ImageList (from ComCtl32.ocx) and Calendar (from MSACal70.ocx) - if the client updates MS software (e.g., Office) and selects the option to install ActiveX controls, my app's ActiveX controls don't work.
>>
>>The calendar comes up with everything black - was the 'default' of light gray - or with an error that Property VALUE is not found.
>>In the form which contains the Calendar, the OCX was actually changed!
>>Was supposed to bs MSACal70.ocx - changed to MSCal.ocx. It's the new version, but I don't want the new version, since I coded it to work with the old version.
>>The form which contains the TreeView and ImageList throws a Class Not Registered error for each control.
>>
>>Should I just abandon use of MS ActiveX controls in my custom apps?
>>I can't recode and have each client reinstall everytime they install an MS update.
>>
>>What is the way around this?
>
>I just got done reading in another thread that VFP apps will break if you change the version of the Active-X control. I don't think that there's anything you can do about that. Just a guess, but maybe if you put the ocx in your app dir instead of the system dir it won't change it? Sorry this isn't a soluion. But I thought I'd confirm that it is a VFP problem and not that you're doing something wrong.

Not if you add the ActiveX control at design time; if you add the control using AddObject() at runtime during the Init() event by ProgID, you should be able to deal with updated controls, as long as the functionality is a superset of what you originally expected, and doesn't require you to do anything extra.