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,
>>
>>Your arguments are certainly appropriate. However, I woudl propose to you that the current problems that VFP has with ADO (which is the VFP cursor engine) is directly related to the fact that VFP's UI components are not windows standard objects. With VB they are the standard windows objects and tehy behave better with the other windows technologies.
>>
>>I don't have a problem with girds, I just hate them and avoid them at any cost :-).
>>
>>If morphing VFP into a full featured object oriented development language for buidling middle tier objects will eliminate the current problems with the apartment model threading, the interaction with ActiveX controls, the huge size of the runtime libraries in their memory footprint, and the other weaknesses that VFP has, then I say go for it.
>>
>>When it takes a couple of weeks to get up to speed building forms with VB, I don't care if VFP has a robust UI layer. As long as I can use the power of VFP for manipulating the data.
>>
>>Many people don't relaize that the reasons VFP has problems with ADO and RDO is the very architecture of VFP's UI layer. If MS continues to spend time and money trying to fix something that is inherently unable to be fixed, that is a waste of time. I would rather see MS change VFP's architecture, make it smaller and leaner, specialize it, dump the "everything including the kitchen sink" nature of VFP, and even change its name.
>>
>>If getting VFP to be lean and mean means that sections of it must disappear, then so be it. My clients don't care if their app is built using VB and VFP or in VFP only. What they do care about is that the app can grow with them and their business. That they can find talent to maintain the app over a long period of time. That their business needs are met. That their problems are solved.
>>
>>If I needed an operation, I certainly wouldn't want the surgeon to use technology from the past to solve my problem, when better more modern technolgoy was available.
>>
>>This is not an issue of technology for technology's sake. The N-Tier design model allows for the enhancement of applications incrementally without requiring that a change in one layer cause changes in other layers. It centralizes the business logic so changes in it are propagated to every UI in use. VFP's local data engine is ideal for creating meta data system for business rules. Using this type of design allows the business rules to change without recording the middle tier object (data driven business rules).
>
>You just released a big load off my shoulders.. I tought my allergies to the grid were a change-resistance psychological reaction of mine. It's good to know other people feel the same way about it (for some human-nature unexplainable, unreasonable grounds).
>Crescencio