Hi Rick,

I greatly appriciate your comments here. However a few comments.

>I think it's important to keep things in perspective.

I'm aware that things grow out of perspective as a thread like this continues. Yes, I guess I'm guilty of getting dragged too far away because of my disagreements with mr petersen.

>But on the other hand you get an environment that is extensible! You can build custom controls and controls that are more efficient than thte stock controls. In fact, I'm using a library called SandBar right now that sort of does this with things like toolbars and menus and greatly improves on native WinForm performance of thsoe components.

>The point is that if you really want good performance you can eek it out of the system. You can't do that with VFP for example - you're stuck with what's there for the most part.

Well you can, but then you've got to rely on thrid party activeX controls. They sometimes are not 100% what you need, but at least you've got a choice. As you gave as an example, the replacement for a statusbar (statusbar activeX control) is not perfect as it does not comply to XP themes, but it at least is way better than the native one. If you are going to do graphics there is a whole army of third party controls out there for purchase.

>And there's plenty of 3rd party activity out there to provide you with what you might need both free and for a fee. Try to get a current Menu/toolbar component that works with VFP these days for example... if you care about building modern looking applications the lack of new ActiveX controls that provide up to date UI is a big issue. And it will only get worse with VFP as there surely won't be very many new ActiveX controls coming out in the future as all those vendors have moved to .Net.

I'm not to sure about that that as VFP is not the only language out there not complying to the .NET world. There are still a few million VB developers with the same or worse problems, which is a large market. At least for now. OTOH, You maybe right on the long term, but I don't like to look at the long term as many things might change. Future VFP versions might support better .NET integration or .NET shifts to a new technology for what we now call ActiveX controls.

>As anything you need to know your pros and cons and HONESTLY evaluate them. VFP's strength is its local data engine - you can use data for just about anythign.

In fact that is the thing I've been hammering on. The day that I will leave VFP, I'll surely miss this beloved feature.

>In .Net you have more situations where you'll use collections or other storage mechanism. .Net's strength is it's flexibility and the sheer breadth of functionality available. You can't possibly understand this and see it this way until you use it comfortably. But again that depends on your level of coding too. If all you do is build functional, but ugly data entry forms all day then it will be hard to appreciate the breadth of functionality.

IMO, Flexibility needs to defined more closely. On the UI might agree indmediately, however when it is about datamunging I've got serious doubts.

>If you're (not you personally) the kind of person that uses SQL statements in your UI front end code then yeah, you will complain that you write ALOT more code that you do in VFP.

Well I do, but in a layered manner. Not in tiers, but in layers (biz objects). And of course the datamunging for display in grids, other buisiness mechanisms as menuhandling, security, a custom Query designer etc. Definitely not something that you will try in .NET without questioning if this is a smart move from a theoretical and practical point of view.

>But if you use business objects or abstract most system objects you access into higher level application objects you will find that the code is nearly identical.

From the UI perspective I assume. What about the middle tier (biz objects) ?

>Performance comparison: Web interface: significantly faster with .Net, Windows Forms Interface: Significantly slower than VFP at least at startup. Once up and running app is slightly slower. Both interfaces are using SQL Server as the backend so this is (subjective) apples to apples comparison.

I've never dismissed .NETs validness of running WEB. The slowness of Winform is an argument, but what concerns me the most are the stories that MS is going to change winforms within 4 year in such manner that you'll have to a conversion again. Can you react on this runour ?

One thing though, not many developer seem to understand is that even in a C/S situation there is a lot VFP can do for you. In stead of datamunging on the SQL server, I'd like to post process downloaded data. This aspect is very important to me and is commonly used in ERP environments as well. You can get your raw data from the server and have to post process it into a form that is convinient for for example reporting, (but not report, exclusively). IOW, I'd like to build data driven applications that do a lot of data processing on the client side. For these type of applications it seems no fun mudding arround in ADO.NET.

>You guys rooting for VFP really need to get off your high horse to think somebody is trying to rain on your parade about VFP when they're moving or experimenting or saying something nice about .Net. This is not a competition.

I'm not sure what you're trying to say here. Our main objection is against the VFP is dead song and the way that JVP is singing that. We 'VFP rooting boys' are merely saying that even today VFP makes sense in an awfull lot of situations, esspecially when it comes to datamunging. We highly object against the message JVP is spreading: We all should move to .NET because that is the future. We've been hearing that for arround about 10 years now and have seen new technologies like VB, RDO, RDO2, ADO, Java, various Access badly upgradable versions come and go, so if you learn from that past there is no reason to jump just every new tech wave. People have been there and learned from that experience. There is too much at risk.

>Applications aren't only about performance and how many lines of code you write but also about functionality you can provide. And .Net has a much bigger functionality range than VFP does. There's a lot to be said to be using the same tool for desktop, Web, mobile and whatever else comes down the line. Don't underestimate this aspect!

Ohhh, I have no doubt that MSs x billion investment is not just about VFPs marketplace, In fact I think it mostly is not about VFPs marketplace. Surely they have an significant overlap, but I firmly believe in situations where VFP makes sense over .NET. I have no doubt that .NET will improve along the line and certainly will improve on the data handling side. As you said, .NET still has a long way to go. We will be waiting until the time that .NET or VFP close the gap. Maybe in the far future we will see a VFP.NET version and makes life for us mortal VFP developers a bit easier to port our existing application to a new platform.

I have to agree with your comment about using the same tool for different platforms. However I still have to see how this is going to evolve. As a VFPer with C/C++ skills the jump to C# does not seem to be a big one. However as always with learning new language there is a steep learning curve in knowing all classes and what they can do for you.

Walter,