>>Just one more note on this. From what I can tell, if the file already exists if the version date is equal to or less than the version date of the new control, the extension is changed (to *.oc$) and the new file replaces it. Note, that it's the internal version date of the file, and not the time stamp. Even if the time stamp is later, it gets overwritten. I've seen the behavior first hand.
>>
>>As a side note, if you want to find out what the version date of a control is, you can use the GetFileVersion() function in foxtools.
>
>Thanks for the info, George. One related question, if you don't mind: do you think there could ever be any trouble if, for example, a vfp install overwrites an older ocx that, say, a VB app uses?

Well, it shouldn't be, but it could. Any application, however, may not know the difference. I hate to hedge like that Bruce, but here's my experience. Knowing the problems with the Common Dialogs control, I went out looking for a more recent version, which I found with the VB Control Creation Edition at the Microsoft site. I installed it, and began getting OLE errors when I tried to access the property sheet for the control (not the regular properties form) in VFP. I found that I could programmatically set the necessary values, and, at runtime, everything worked fine. This problem disappeared when I later installed SP 3. I have two takes on this.

One, that the problem I originally experienced after downloading the update controls was one connected with proper installation, since once SP 3 was installed, the problem disappeared. Same version of the OCX (even though the VBCCE ones had a later time stamp, but same version date, etc.).

Two, and this references a recent thread about ActiveX and VFP and VB, even Microsoft has its problems when it comes to the creation and installation of these controls. I'm pretty tolerant in this area. This is a relatively new technology, that has loads of potential, so I'm kind of forgiving for the time being. A year from now I won't be.