>Don't worry George, I never think you're "preaching". I value your opinion on lots of topics, especially when it comes to API and "lower level thingies" within VFP. But since you brought it up, if there is no longer any support for the Mac, why do we have to continue to "pay the price" for it's support?

Appreciate the kind words, Fred.

What would have to happen is a complete re-build of VFP practically from the ground. When's the best time to do this? When the underlying OS undergoes a significant change. For example, when we went from Win16 to Win32, we went from FPW to VFP. The next version of VFP is targeted for Win64. So as I've said many times before, if something like this is to happen, we'll see it in the next version.

>>Now, let's assume that both used real windows for the controls. There'd still be a possibility for difference. For example, both VB and VFP forms are real windows, yet VFP has nearly 3 times the PEMs. The difference? The implementation.
>
>
>So, do you think this will change any in VB when they get a more complete OOP model?

Hard to say, but what we've heard would bear out the point I made above. The VB team will have to decide what features they're going to implement in their form class. Personally, what I'd like to see is a convergence in terms of the PEMs with each having the same. I'd also like to see a greater similarity in the design interface.

With all the talk about "using the right tool for the job", it would be a lot easier to do if you could work the same way in both products. You wouldn't have to remember which product you're dealing with. For example, in VFP it's the Init event, in VB it's Initialize, in VFP there's Destroy in VB there's...Terminate (I guess, I don't know if this is an exact match or not). Anyway, I think you see my point here.