>George,
>
>So what if it is a "major undertaking" to VFP??? Here we go again, making excuses to let VFP folk weasle out of something important and necessary!

Naw, I'm not making excuses here, Jim. What I'm talking about might even require a total re-write of VFP. If so, there have been substantial reasons for doing so, and it must (by definition) lead to a much improved product. Being interested (as you know) in the API, I'd love to see structures and pointers be made available. Structures are one thing, and as far as I know, could possibly be implemented without losing a thing. Pointers are another matter. Given VFP's current memory management, that would have to be re-done in order to give us pointers and callbacks. However, unless I'm very much mistaken, it's that same memory management that makes VFP the best performing data manipulation product available. If that's the case (and I strongly suspect that it is), and if we got pointers and callbacks, we'd probably take a major hit in data manipulation performance. As much as I'd like to see those features, I sure wouldn't want them at that cost.

Same holds true with getting real windows objects. As JimB pointed out, it would make the product more difficult, rather than easier, for quickly developing solutions. Further, I certainly don't want to see my current investment go right out the window (no pun intended), just so that I can use a few ActiveX controls. Especially in view of the fact that, in VFP 6.0, the majority seem to work just fine. Again, the cost is simply too high.

Now if, and that's a really be if, all this could be without sacrifice, I'd say "Sure, go for it".

>I wonder why we cannot just tell MS/VFP what we need, why we need it, and let them generate their own EXCUSES???? As things are now done, they have plenty of well-intentioned but uninformend people speaking *FOR* them, allowing them to remain mute on such important issues.
>
After reading the above, do you still say I'm making excuses?