>Same here (not trying to be argumentative :o) While I agree that one of the benefits of the current method of subclassing is what's learned in the process, I don't think that justifies it being the only way to do it. Visual subclassing and hooking (and then of course the ability to go into code and fine-tune it) should be an option in any gui devtool today (even if the encapsulation rules technically prohibit it). There are cases where it could be done without breaking all of the rules though so it could be available on a limited basis. Sometimes I think the ability is just not there so folks will be forced to use interfaces (ok i agree with that but there are simple inheritance stuff that could be done visually)
>
>Thanks for the observations. I don't deny that visual subclassing would be nice - however, often do most people spend building subclasses? That's why I've never found this to be a serious argument.
>
>I agree with the LINQ statement, but so far I haven't been able to truly match the speed of data crunching available in VFP. Now I also honestly don't think most developers will ever recognize the difference because most apps don't have a need for intensive data munging and will be quite happy with the what's available in dotnet today. So in general, I agree that .NET can hold its own in that area, but not for serious data work (yet). I know of a few large developer shops (>14 developers and some with >30) who are rewriting VFP apps to dotnet apps (with MSFT's costly help in a couple of cases) and so far .NET cannot match the speed of the original VFP app. There's a lot that goes into a real discussion on it (models, layers, threading, async, objects, security, contracts, etc so it's not really a discussion to have between the two products) These are generally special cases though and I think the typical app can be just as fast and professional looking (if not more in fact) in .NET
>
>Remember that by moving from a VFP app to a SQL/.NET app. you will very likely achieve greater back-end performance and economies of scale. I won't say never, but it's going to be unusual for a VFP app to seem faster overall to end users than a converted app using SQL Server and .NET.

Given the same backend and only the front-end changing (VFP or .Net), my experience has been quite different. I've seen dev shops spending a large portion of their time trying to find ways to make the .Net app 'appear' as fast as the VFP app.