>J.
>
>You and Jim (and others) have adopted a "solution" to the Grid problems which many others can't, for one reason or another, live with.
>
>Mine is, by the way, similar - only when I *have to!
>
>But that is no reason to leave the situation with Grids alone - they ought to be fixed up and better documented. Looks like that will not happen, with the direction being mid-tier.
>
>Cheers,
>
>Jim N

Jim,

I think your logic is flawed, A does not necessarily lead to B. Making VFP focused at middle tier development does not necessarily preclude improving the UI and database aspects of the product.

It does, however, require a rearchitecture of the product so it can participate better in the COM/DCOM arena.

Pure conjecture, the product could be split into more than one product, a UI development tool, an Object Oriented COM/DCOM development product, and a local data engine.

The VFP cursor engine is already the basis for ADO now. If VFP became better at using ADO and ADO became more full featured in it data engine, then where's the problem of using VFP to access data through ADO? Also if forms are easier to build and maintain in VB, why use VFP to build forms? You can build them with VB and access the data using VFP in the same system.