>>
>I wonder WHY you are so sure that this would slow down VFP applications??? >Obviously this would be unacceptable to the vast majority of VFP users. But >this alleged slowdown is all theoretical and we should have sufficient >confidence in the VFP Team at MS to find ways around such "problems".

Not if it is a Windows issue that the VFP team has no control over.

>As for the native controls not having many of our properties, events and >methods, this is again an issue for the highly talented VFP Team (and not you >or me). My answer to your supposition is yet another supposition. . . that the >VFP Team could 'sub-class' the native Windows controls to endow them with the >required (missing) functionalities. Yes, I know that in VFP **WE** cannot >define additional events BUT who is to say that the owners of the Windows >controls cannot do so???? I have to bet that they, in fact, **CAN** define >just about whatever they feel is needed for any Windows control by sub->classing or by some other means unknown to us.

NOt necessarily. If the hooks into the events don't exist in the first place, it may not be possible. What you're saying is that if the need functionality doesn't exist, add it....that's what they have done! We already have it.

>
>And have they ever gotten an answer to this... and have they listened??? And if their answer is that there are "D/COM" ways to achieve the same end, then have they clearly said HOW, and is the existing VFP documentation clear enough on the subject???

Is any documentation really clear enough?

>
>Regards,
>
>Jim N
>
>
>>>
>>>Regards,
>>>Kueh.