>>>Hi Ed,
>>>
>>>Very true, but I think that it's more of a reason to sub-class the control.
>>
>>Or better yet, don't add the control to the form at Design time in the first place! Add the control at runtime using the ProgID (easiest if you instantiate a non-visual class to wrap the ActiveX control on the parent container (form, page, whatever)), so that you don't care which one is present as long as more recent versions support the same functionality that the older version did!
>
>Have you been looking at my Obj2Bmp code< g >? That's exactly what I did for both the TreeView and ImageList so that the control version would be dependent on which version of VFP the thing was compiled on.
>

You left out < SHAMELESS PLUG MODE ON >. Seriously, Obj2BMP is a great tool, and I'm looking forward to any enhancements you might make. It's saved me an incredible amount of time documenting things. If I haven't already thanked you for letting me play with the beta, THANKS. It's the best thing since sliced bread to come along, or at least since SDT... :-)

>Seriously, I even attach the Common Dialogs control to a command button via a straight CREATEOBJECT().

So do I, you're preaching to the choir here. And now, with VFPCOM's abaility to provide wrappers to let you add VFP code to ActiveX control events directly, there's even more reason to do this.