>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.
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'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.
No it surely isn't, but the major other choices are:
Java
Delphi/Borland Tools
What's left of the VB crowd
The first two are not a market for ActiveX vendors. That leaves a fading VB market that nobody is going to invest money or development effort (for 3rd party products anyway) into.
>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 and once you get over the difference of how the environment work you find there are more things alike than different. Then there are the things that have always been bad about the DBF file format like PACK and REINDEX. It's all a matter of how open you are to doing things a different way that gets you the same results... I really like the fact that I can run Profiler to see what SQL is getting sent to the server, that I can use generator tools to create synchronizign database code for me, that I can access my Sql Server remotely over my broadband connection on the Web Server. I can do all those things with VFP too, but I have/had to build it all.
>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.
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.
>>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.
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.
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.
>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...
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.
>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.
>>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.
Well, but everybody gets up in arms when this argument comes over and over again -it's that self-fulfilling prophecy. John is John and you all know that. If you don't like what he has to say ignore him. Don't feed his ego... It's that simple.
>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.
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 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.
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. 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.
