>Hi Goerge
>
>>BTW, I assume that if you're referring to VFP class files, the answer is no. It simply provides a consistent interface that a language can address. Originally, these controls (16 bit version) did have a VCX extension. This was back in the days of VB 3.0, however. When MS opened the VB architecture to allow 3rd party controls it was the beginning of what we now refer to as ActiveX controls. One thing that was changed in the conversion to 32 bits was that the extension changed.
>
>what I meant by comparing OCX to VCX was not in the likeness in file structures and interface but the parrallel between a VCX being a library of class and an OCX being a library of ActiveXes. ie:
>OCXA v5 contains 2 ActiveXes: AXA v5 and AXB v5
>If AXA is updated two v5.1 than your method that checks th OCX would retrun 5.1 even if you are checking AXB

>This is all a guess on my side because I don't know any of the rules ActiveX developers follow.

I understand now what you meant, however, I don't think that it really applies. ActiveX controls are really nothing more than an easy method of interfacing with a DLL. A good example of this is the Common Dialogs ActiveX control. It doesn't produce a single dialog on its own (with the exception of its property sheet, which is still an API call). The various dialogs that you can invoke from it come from the DLL. Where problems arise occurs when the physical representation of the control can no longer properly communicate with the OCX. This is probably prime reason #1 to sub-class ActiveX controls using CREATEOBJECT() or a prg.