Hi Rick,

>Well, but that's always been a problem. A lot of ActiveX controls don't work very well with VFP. Never have. Even the provided ones have a number of quirks only in VFP (not in VB) and a lot of the stock controls already aren't being updated for example to provide themes support.

I know, this is not al sunshine in this area, well at least I have no big problems right now with activeX support and VFPs themed controls. I guess if you don't set the fancy GUI to the highest priority you should be fine. This is a problem that has always been there, and you're right from a visual standpoint it is not going to be improved in the near future. Anyways if this is your high priority you would not program in VFP anyways.

>Java
>Delphi/Borland Tools
>What's left of the VB crowd

What about MS access ?

I surely can't help the feeling that a LOT of current applications will suffer from the same problem. I guess the most urgent problems will get sorted out, but your right the glossy and fancy little thing probably never will.

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

>Well, there are other ways to deal with these things. I can attest to that, have been dragged kicking and screaming into using SQL Server for many things over the years. VFP is easier to work with but there are also many things that are extremely useful with using SQL Server.

Not a word from me about the usefullness of having a database server. My point is that they certainly are not mutual exclusive esspecially when handling downloaded data in cursors for post processing. Like you said, post processing data for reporting.

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

>Well, ADO.Net is very rich. You have offline data out of the box - you're not connected and it's an object that you can pass around - to other applications or internally. This is not trivial to do with VFP. You can of course with a bus object layer, but that's your own work. The whole data engine is an object model that logically laid out and you can get all information about data at runtime. You can dynamically define data once its been retrieved.

I'm not interested in those features as they can be done in VFP also, though you have to use a variaty of functions.

>It's just a different metaphor but in my opinion a good one UNLIKE a lot of the other crap that came from MS before.

From a theorectical point view, I object against the object solution, as IMO data should be handled relation, not by iterating through object for datamunging. Esspecially If you want to do advanced data munging with e.g SQL commands on local data (thus after you've downloaded the stuff), you're having big problems with ADO.NET in its current state. In the DB world there is a common consensus that data should be handled relational, not OO. Application might be written OO, but the data should be handled relational. Virtually all data is relation, OO database did not make it in the 21st century. I object in getting and setting my data in an OO way by handling collections. This not only from a practical standpoint, but also from a idealogical one. We have a standard when handling relational data and that is SQL. If other DML technologies are supported, fine, but at least give me a reasonable extended set of SQL.

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

>Ah, but you see you're making assumptions. This stuff likely wasn't a trivial thing to build in VFP either. Of course you can do this in .Net and it is acutally likely to be easier than in VFP because for those sort of generic things its much easier to get runtime type information on your data and running through your data. This sort of stuff can and is being done all the time.

I don't see that. What exaclty do you mean with getting type information? I can type information about any field I want (not that generally need to do that anyways).

Handling data is not easier in .NET and as you said almost always slower. You don't have the ultimate flexibility of record oriented and set oriented DML at hand which burdens you to do advanced data munging. Of course there are a lot of other things to take care of as well. For example I could easily include a table or database into an executable, whereas within .NEt I've got to find another suitabled an quick solution. I've not seen one yet that is as comfortable as within VFP.

If you do a lot of SEEK(), KEYMATCH(), SCAN FOR WHILE, LOCATE FOR WHILE, REPLACE FOR WHILE, SET ORDER, INDEX ON, SQL SELECT, etc you've got to find workarrounds for that. You have to build your own classes which are certainly slower than the VFP equivalent because in VFP it is just one command. Granted there are different ways to skin the cat, but my first goal for these internal data intensive task is always performance.

>What is scary (and I will be the first to admit this) is that whenever you make a tool switch you will end up rebuilding things that you already had. Slowly. This feels like wasting time. But in the end you've gained a new skillset and have learned much about the new platform.

True, there must be time to do this.... Unfortunately time is even more scarse than money up here, so all I can do right now is to study some material and do some reading.

>>From the UI perspective I assume. What about the middle tier (biz objects) ?
>The business object application logic is the same between the VFP and .Net code. In VFP I get cursors (mostly) in .Net I get DataTables. This logic is not much different...

What about advanced report generation ?

>The actual bus object framework code too is not much more complex than the Fox code. That's because writing truly generic code in VFP is also not exactly trivial.

Agreed, complexity of general programming concepts was never any argument IMO.

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

>I don't argue the fact that VFP is a bad choice. It isn't. I'm arguing against the fact that .Net is a bad choice.

It is my strong believe that in a number of cases where performance of advanced datamunging is an issue .NET is not going to be your first choice. I clearly see advantages in VFPs strategy of handling data.

>Well, Microsoft has said on a number of occasions that there will be no .Net version of VFP and frankly it wouldn't make much sense anyway. you would likely use the dataengine that you love so much... and then what's the point <g>...

I recall, that there will be no .NET version of VFP in the near future. One reason for that is the fact of the local database. If this gap is closed by future .NET versions it might be that this is not a valid reason anymore. However it is useless to speculate since either me or you can look at the future.

>With .Net the learning is not in the language its in the framework. Learning a language is easy. Learning a framework is a real bear and it takes time. Microsoft obviously is betting on this one and there's plenty of momentum moving things forward.

I know and agree. Let's see how .NET is going to evolve without going through the pain that comes when a language grows to maturity. I don't think .NET is mature enough to justify the jump right now. We've got a valid platform, we can build our applications and we know that porting our existing VFP applications to the next VFP versions is going to be far easier than jumping .NET. Certainly if you know the risk, that you've got to convert your software within a few years, you'd better step back and watch how things evolve.

>The key thing that will change the .Net movement will be when the OS itself is based on .Net which is coming although still a while off.

Are you talking about Longhorn? or the release after? Well if I'm correct the future of the Windows OS is that it is build on database technology. When I try to search on my c-drive for a specific file I everytime think that it would be truly an inprovement if the filesystem was based on database technology. And this is just a very simple example. There are lots more that makes you wonder why the hell displaying a simple list is taking up so much time (Display all installed software comes in mind).

If you extend this to development tools you can't argue that VFP itself also is build on database technology. Forms, Classlibraries, Reports, the project Manager is build on database technology. This is one of the reasons why VFP I find VFP so great. I don't know about the internals of .NET, but I wonder if this is the case up there. I've got the impression that .NET has a long way to go before meeting that goal.

Walter,