Hi gerry,

>>Things that to me are so invaluable that I will feel crippled in .NET with the absense of a local data engine. Don't get me wrong, though I'm not an expert in .NET I do know these things are not impossible, but they certainly are harder to do and most of the time a hell lot slower than within VFP. I think part of the problem is that some people do not see the huge value of data driven applications.

>For the sake of argument, the VFP ODBC/OLE Provider coupled with a DBC and stored procedures provides a "local data engine".

Well, certainly a posibility, however not a real solution for highly data driven applications either. You still have very much a distinction between the core program and the dataengine.

>The "problem" I'm beginning to see is that while data management is such a joy in VFP, I often resent the mediocure UI, printing, graphics and API support in VFP.

Well. The UI often is limited by the programmer itself. Programmers are not UI designers but often they try to. I'm not sure what kind of GUI you want but ActiveX plugins can provide what you need. I've seen many poor UIs but seldom they were the result of limitation of the language but rather the lack of creativity of the programmer/Designer. In itself I've got no problems with the VFP GUI.

Printing is another issue. I've identified long ago that the VFP report writer was not sufficient for my goal. Luckely Crystal Reports intergrates quite nicely within VFP. Appart of a few minor issue I'd like to see enhanced I've got no wishes on this side. Note that .NET ships with a simular version of Crystal Reports also.

API support. I agree that handling Windows API sometimes is harder than in other languages. However with the help of Christofs struct solution (available from the downloads section), C/C++ and custructing a FLL Library this could be overcome. Also with the great resource like the UT, the chances are that someone from the UT has solved the same problem before.

>Clients are still often more impressed with what they see going on in the Screen than under the hood ... and personally, the lack of "flash" capabilities in VFP can get pretty boring even from a developer's point of view.

I'm busy with a large medical project. The early preview version beat the DELPHI competition because its GUI was far better. Creating a good GUI is an ART rather than a craft. Trying to fancy up your GUI with all kinds of fluffy things might only be an attempt to hide your mistake in GUI design.

>While everyone continues extolling the merits of a VFP "front-end" and a [blank] "back-end", I'm starting the see more merit in a .NET front-end and a VFP middle-end and/or a [blank] back-end ... simply for the sake of keeping my level of enthusiasm up for the next x years.

I still am not convinced of a three tier system for regular windows applications (Internet applications not included). IMO you're creating more points of possible failures and unneeded complexity and limitations. If it was up to me, a n-tier solution for regular windows applications is a NO NO.

Walter,