>>>Just wondering if any one know if there is a way to determine the version# of an activeX control programatically in VFP. i.e. I want to find out the version# of the calendar control at run time...
>>>
>>>Any help is appreciated !!!
>>>
>>>Thanks.
>>
>>If you know the name and location of the OCX file, all you have to do is pass it, along with an array to AGETFILEVERSION() (or GetFileVersion() in foxtools for VFP 5.0). The fourth array element will contain the version.
>
>I almost suggested that, but will it nescisarily work? I thought the OCX file is like a VCX file with multiple classes. That means two different versions of an OCX file might have the same version of a component within the OCX. So if I'm right (no clue really) you would need a large library of Component version to OCX version cheat sheets.
>
>Unless the version of the component is automatically assumed to be the same as the OCX by MS Standards (I know its an oxymoron)?

Hi Mike,

AFAIK, an OCX file must always have the necessary format in order to interface with the various languages that call it. I've never seen one that didn't have the version tab available from it's Explorer File Properties dialog. This includes controls from sources other than MS. So, this should work.

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.