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

George,

Just a minute, and for the rest of us ...,

Are you saying that, in your view, (which amounts to fact in mine:)),

1. to get VFP as a product closer to what MS, and the industry (quoting Jim B), regard as a mainstream product, would require no less than a rewrite.

or 2. it are the unique features of VFP that, i.e. even if resources for rewriting would be allocated, make it improper as a mainstream product.