>I stick to my opinion that WinForms are still lacking within the confines that I mentioned in previous messages here. Mainly performance of the UI, which is abysmal even if compared with VFP which compared to just about anything else is also slow.
>

I have not seen this "abysmal" performance you are referring to. For example, I developed one form that had 6-8 look-up combos and 6 tx tables. Basically what you had was a series of parent, child, grand-child, and great-grand-child relationships (all managed with dataclas.net). Just to get the data, there is at least 12 trips to the server. I found the screen refreshes to be as good as Fox - or VB 6 for that matter. IMO, this was the mother of all screens as it showed a lot of data for "at a glance efficiency". If winforms had an inherent performance problem, I would suspect that problem would have been manifested in this screen.



>
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.
>

This is a good point. Innovation is the name of the game and when MS made its big announcement regarding ActiveX - that was it. Anything that was Activex/COM based was not going to be the benefactor of significantly new innovation. Would it be supported? Yes. But innovated? Not really. Using you and Kevin as examples, you like many vendors have made the strategic decision to get into the .NET world.


>
...And contrary to what some people are saying here the amount of code written is not any more complex than what I used with Fox. If anything the way I have my bus objects and controls set up these days there's less code and better abstraction. That part is software design and although there's more code in the innards of those objects, those objects are also a hell of a lot more flexible than what I could do with VFP.
>

Good point. The same was actually true with VB 6 as well. While VB 6 did not have implementation inheritance, the combination of abstraction and aggregation - for the most part - took care of the lack of implementation inheritence. Of course, I would rather have it than not - and it is nice that .NET supports it.

>
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.
>

I would modify this to say that VFP's strength is its *integrated* local engine - assuming you are building what could be classified as a monolithic application. As you break your app apart into components, this integrated local data engine loses its effacacy. In terms of performance, ADO .NET performs extremely well.



>
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. 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.
>

Indeed. The problem I see is that many look at .NET in "VFP Terms" - and as a result, become disillusioned and disappointed. This is similar to the whole "transparent database" argument. At some point, to take full advantage of a database backend - you need to code to that database. For example, in order to take advantage of an Oracle context index, your sql statement has to be formulated a certain way. Sure, you could stick to generic SQL - but you would not fully exploit the power of the back-end. The same could be said for how you do full-text searches in SQL Server. In these cases, you have a choice. The worst would be to embed SQL in the app itself. A better solution is some sort of middle-ware that acts as a broker between the UI and the database. In this regard, to the UI, the database is transparent. To the middle ware - which would have a separate version depending on whether you were using SQL Server, Oracle, or whatever, the database would not be transparent. Alternatively, you could move all the language to stored procs, and leave the middleware constant. IMO, this is where the crucial decisions come into play. On one hand, you may want your business logic hosted on a different piece of hardware - apart from the database. On the other hand, you may want the database server to host the business logic. What is the right answer here? It depends.


>
I can attest to this as I've just gone through the process of porting the West Wind Web Store from Fox to .Net both the Web interface and the Windows Forms front end for it. I can tell you that the Fox version is not any smaller in terms of lines of code than the .Net version. If anything I think there's less code in the .Net version even though it has a lot more functionality. The power of abstraction.
>

People that have truly embraced OO I believe, have reached the same conclusion.


>
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.
>

Again, I have not seen the performance degradation you have seen with Winforms. I see that you have drawn a distinction between start-up (which is a one time issue) and the running of the app. In your opinion, what do you think is happening at startup. FWIW, based on all the advantages you enumerate re: .net - a slight hitch at startup - assuming it is there - seems like a small price to pay.


>
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.
>

Well Rick, I would disagree in part. To a VFP-die hard cheerleader - it is indeed a competition in their mind. At some point, these people will realize that being pro-.NET does not equate to being anti-VFP.

>
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!
>

Clearly, the serious work that needs to be done is how to effectively write desktop apps for .NET. For the majority of VFP developers, they could not care less about web/mobile apps. IMO, this is the biggest nit for VFP Developers who are less than enthused about .NET since there is not an integrated local data engine. This is why it is likely better to say that with VFP - the best "perceived" strength is the local data engine. Unfortunately, this "strength" has hurt the ability of some to look at how applications and data interact. VFP is over in one area and the rest of the world has gone in another direction. i.e., skill sets are directly tied to the toolset - instead of transcending the toolset. And this is why Rick - to some - it is indeed a competition.