I was drawn to Strataframe because I was basically looking for VFE 9 for .NET. What I found was VFE 6 for .NET, but that being said, it has the most important parts - short on wizards and builders, very strong on internal design and the important plumbing. Also a very deep brain-trust of folks working on making it better ever day. They have gone pretty far with some goodies like role-based security, localization, serialization, connection handling, wizard controls, dynamic sql query builders, SMO management ofo SQL servers, and of course strong-typed business objects, so I can accept waiting for RAD stuff while I have this kind of stuff to shield me from some of the uglier parts of data in .NET. The VFE, VPM, VMP guys seem to warm up to it pretty quickly (though of course we all beat on the Microfour guys to give us more wizards and builders as I'm sure you guys do on Kevin <g> and I'm sure that in time that will come.)


>Good points, Charles.
>
>I totally agree with your statement about not wanting to develop VFP apps without a framework. I've been using Visual Promatrix for years, as well as VFE on occasion. I'm thinking that getting VFP to compile in .NET is 60% of the ideal solution. A framework such as VFE or VPM on top of that would make it a huge productivity booster compared to any .NET development out there today. MM.NET is quite good as a framework, but it still doesn't provide the kinds of builders and metadata dictionaries I've been used to (and spoiled by.)
>
>Pertti
>
>>And it works very well. And .NET frameworks that use strong-typed business objects can certainly manipulate data as easily as VFP. I can fill 15 cursors with data on one trip to the server with one SP call, then handle those local cursors as I would queried remote views in VFP. I can filter, sort, fill cursors by parent pk, scan, do queries against temporary cursors in to other temporary cursors. And I can serialize snapshots of business objects - including the entire state of their data - with a single command, store them if I like and deserialize them if I need them.
>>
>>My only beef with .NET at this point is I miss some of the wonderful RAD stuff Mike and Toni made available to us in VFE and I am still adjusting to not having DBCX. A lot of the data handling power in Strataframe (and I would expect MM and probably a lot of frameworks created by others) comes from extending the .NET framework with datacentric functions and subroutines to manipulate the data, but that is not exactly rocket-science, just creating classes to do what you want them to do and making them part of the framework. It isn't .NET out of the box, I don't consider VFP out of the box a particularly good development tool either. VFP without a framework is an invitation to writing old prgs. VFP can be awkward and development-time consuming with data too ( assuming a SQL server backend since I gave up DBFs a while ago) but it certainly can be pretty powerful with DBCX driven remote views or skill with the cursorbuilder.
>>
>>If I can ever convince somebody like Toni to apply her gift for RAD tools to Strataframe, there is certainly the potential in the .NET IDE for wizards and builders that could easily lead to develop data-centric apps as fast as I can in VFE.
>>
>>I really want to see the VFP .NET compiler finished, as I'm sure it will be very useful, but I don't think it is necessary in order to have pretty much everything in .net we love in Fox. It will be another useful tool and will save a lot of development time - especially when there is a part of an app that contains a whole lot of convoluted business logic that can be brought over as one nice black-box dll into a .NET app.
>>
>>But for new development, I can't imagine going back to code it in VFP so I can compile it for .NET.