>>>>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... :-)

Actually, I think the appropriate command is SET SHAMELESSSELFPROMOTION ON< g >. Unfortunately, I don't think you're going to see much more than you've already seen. I'm more or less tweaking things and maybe an additional bell here or whistle there. I'm trying to write the doc now (I've been at it for 2 weeks) plus come up with some samples and suggestions. The latter is definetly easier. I just haven't had the time. But I do appreciate the kind words and you and your fellow beta testers will have a release copy before anyone else.

>>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.

And I haven't even gotten to look at VFPCOM yet:-(