Walter,

Your message below sounds like the VB 6.0 people when it is compared to the full OPP features of VFP. The VB people said, "you don't need inheritence" and "you can implement an interface", etc. OF course, people who have used Fox know the many advantages that implementation inheritance gives you. But, the VB folks didn't 'need' it cause they could simulate it.

The fact that you see 'nothing' in .Net redeeming tells me "You don't know Jack" about .Net. Take 6 months to work with it, read the articles about it, read the case studies, etc. While the MAJORITY of the great stuff about .Net is Web apps there is alot of stuff there for Win Form apps too.

>Sure, .NET has advantages too in this area, but of course how often do you need such background processing job ? And if you really need it, would starting a seperate process not be a solution too, though it is not as *CLEAN* as a multi threading option. TO be honest, for the average and even advanced VFP application developer I don´t see much value in this argument.

Cause you don't have it in VFP, you don't think you need it. You don't know what you don't know. Yes, I guess cause of the Windows OS you could spawn another process with VFP, but you have no control over it, no call backs, no access to the events, etc. If you choose to monitor that process with VFP, you've hung up your only thread and really didn't gain anything.

>All of course is about which platform is most suitable for developing desktop applications. There are many criteria involved to make a proper comparison and not all arguments have the same weight.

True, but some of your 'arguments' are just plan wrong or missinformed.

>As I expressed before, I find the data munging capabilities of .NET just terrible because of the absense of a local dataengine, which is esspecially

If you keep banging that drum, it will break. There is a local data engine in .Net... ADO.Net, which is based on ADO which has some VFP cursor roots too.

>important to me when writing advanced desktop applications. I don´t want to manually iterate through collections of ADO.NET to mung my data, nor do I

Man, I wouldn't either. That is what T-SQL is for. Or, if you are using VFP data a stored procedure. Even in the VFP apps I write most of the large batch data processing is done with stored procedures. Could I do it in VFP, sure, but it is less efficient moving all that data over the wire.

>want to use an external source for it (SQL server) for network load abnd performance reasons. In what respect: what does .NET have to offer me. Virtually nothing....

Um, using SQL Server will REDUCE your network load and INCREASE performance, if you do it properly.

>I´m not sure what you say here? but are you refering to automaticly look for updates. This is certainly not complicated and in fact I think many VFP developers use such strategy.

Sure, but they had to build it in VFP code. In .Net, you get it inheriently. OH, and don't tell me that's not better in this case when you main argument is the data handeling in VFP is better cause it is inherient! You can't have it both ways.

>My class libraries are built in the executable, so no problem here also. For application dependant resources, you can store them in the working directory to prevent versioning problems.

So, your users need to update a full EXE to update your app. Which means shutting down the app. Where in .Net, if you seperate your command libs in one DLL and your business domain in another, you can just update that one DLL.

>Other than a universal VFP workstation setup you don´t need to do this for a VFP application as well. I don´t know about .NET, but of course, VFP versions do not conflict eachother....

No, you can't. Lets say you have two VFP apps... One is VFP 7.0 and one is VFP 7.0 SP1. The machine runs both, which version of the runtime is on the machine? Point is, you CAN'T do this, unless you put the correct runtime for each app in that apps folder, which is a maitenance nightmare. With .Net you can have the 1.0 framwork and the 1.1 framework, with apps that runn against each, side by side with no conflicts. You just CAN'T do that with VFP. (Unless you are talking about major versions.)

>>>>Of course, there are alot of things you can do in .Net with 3 lines of code that you can't even do in VFP!!! (Well, you could with a few hundred lines of code and the Win32 api or a Win32 dll.)
>
>Of course! However, It is the question how relevent the ´thing´ is.

Well, I didn't make the '3 lines of code in VFP is alot is .Net' comment. Doesn't that also have to be 'qualified'. But, whoever said it (don't remember who) didn't qualify it at all.

>
>Walter,

BOb