>>>You won't get arguments from me on those (although 64 bit is questionable and probably will be provided anyway once the MS C++ compilers start spitting out 64 bit code more easily).
>However, what do you hope to get out of this? What will that buy you really?
I'm not saying this is somthing I or anybody else needs right now. You were talking about ground breaking enhancements.
>You were the one advocating this enhanced ANSI functionality. This goes along with the next point you asked about: Most people don't write ANSI compatible SQL code in VFP. People who live in VFP and don't code with an eye to SQL have it too easy to forget, with all the cool things you can do in VFP that doesn't fly in ANSI (like using UDF()s or VFP functions in SQL code). Unless you know that your code will port to a SQL backend it's unlikely those things will be considered closely to create Ansi compliant code.
I seldom or never use UDFs() in SQL commands and try to avoid any functions in there too, for this particular reason.
>
http://www.west-wind.com/presentations/foxunicode/foxunicode.aspThanks.
>>Well then we would have a VFP.NET language, hopefully not a too dramatic change from VFP as we currently know it. I do see that on the long term .NET is a better platform for a lot of reasons. Currently it is not up there yet to jump ship for me (and I assume a lot of other VFP developpers), but if we get a language that at least has all the strengths of VFP has I have no problem in upgrading my development platform. I'm perfectly aware what the VFP team has said about VFP.NET, but assuming that .NET will have more data centric features a la VFP, the disadvantages of .NET will decrease to a point where it simply does not make sence to continue development of VFP anymore. So I see that VFP will either merge into another language or simply will the discontinued at some point. This might be years away from now, esspecially since I feel there is still enough reason to use the FOX, but this will change at some point in the future.
>Shrug. I personally would rather not see VFP go towards .NET and just be further marginalized.
Currently I see .NET going towards VFP (VFP data features to be implemented in .NET) not the other way arround.
>At least right now VFP has a good place filling a need that isn't easily filled by Microsoft - which a solid client side application environment to build desktop applications that are fast and don't require a full database engine (ie SQL Server/MSDE).
Agreed.
>>If we as the VFP community have the opportunity to have some influence in the direction VFP is going, I'd say that we should try to go into a direction where we as VFP developers don't have lot of problems in jumping ship, forcing ourselfs into a methology that does not fit with the data centric approach of VFP. Currently the GAP between .NET and VFP is too huge IMO. Take yourself as an example and look at the experience in learning .NET. Sure we all have to learn differences, but you can't tell me that ADO.NET is an improvement over VFPs local data engine. You had to workarround the problems you could solve so easily in VFP. Of course I can hear you say things about portability of data with ADO.NET, That is absolutely true, but that is about the only thing I can think about.
>I don't agree with this entirely. While I'll be glad to admit that VFP's cursor engine allows way more flexibilty in client side data manipulation courtesy of the VFP local data engine, there are other ways to solve big data crunching problems as any SQL Admin will tell you. Doing processing on the server instead of relying extensively on client side processing is one thing. Not using DataSets to pull large amounts of data back for display or manipulation is another as DataSets do horribly with large amounts of data because they are essentially memory based structures (collections).
>Part of the problem is that with VFP we're looking at 'local' data processing often when the real data work should be happening on the server (in SQL). THere are massive systems running on .NET today - obviously it is possible to do this. But it may require other approaches in dealing with data where the heavy lifting is not done on the client.
You certainly have a point in that the 'VFP community' looks for solution for solving data munging on the client. .NET-ers are looking for solutions on the Server. Neither is the right way. It should be processed where it belongs. No arguments from me that is not possible to write massive systems in .NET, but the type of products I'm busy with are not best suited for all server processing. Not only has the architecture be totally reviewed, but it does not make sence to store certain data on the server. I generally work with lots of meta data that is either stored in a database or in the executable. Munging with both local and remote data is very common. Not because I prefer it that way, but mainly because it is difficult to do otherwise.
I'm perfectly aware that the types of applications I write are not found too often. They are very data intensive.
I'm a big forestander of avoiding large SPs on the server doing mata munging. SQL servers are tipically not well equiped for doing that. The main problem that these processes require too much resources. Not a problem when only a few processes are running simultaniously, but a big problem in with larger numbers of users all doing their SPs for reporting or other datamunging services. This really becomes a nightmare when the isolation levels need to set high so read and writelocks are going to block other processes (transactions). There are all kinds of other problem with it as well.
>My strength isn't in data optimizations, and I personally am also a 'client data' guy because the systems I deal with usually make this possible. However in my experience for typical systems that I've been involved with which are medium to largish .NET works very well with ADO.NET's data features.
Whether you do medium or largish is really not a measure for complexity. Most large applications are basically set up very simply heavely relying on a solid framework. Having a lot of tables, forms, reports, really does not tell you anything.
I've had a small project with only about ten tables, but its statistic analysis was so complex that it was far beyond many projects I've done with 50+ tables.
>I feel I have to say this again - I'm not trying to sell anybody on .NET, however I think some of the people involved in this thread don't know what they're talking about when they deride .NET because they haven't looked at it in any detail, or tried some simplistic demo, saw that it doesn't do what VFP does, required more code and dismissed it.
I know you are not trying to sell us anything. I find your message one of the most valuable in this respect.
>I've followed your discussions of what you've been through and I trust your opinion that you couldn't do what you needed easily. But, I also doubt that it's not because it can't be done...
I've got a firm background in the relational theory and do know databases (in fact I graduated on the subject) both set oriented and record oriented. Of course I'm not talking about things beeing impossible in .NET. They are just HARDER or VERY HARD. you might have more problems with resource consumption and performance (when dealing with large recordsets). Writing classes might ease the pain in some circumstances, but in general it won't cut it, because you really have to write classes to create a DML as powerfull and complete as the xBase commands. Else I end up with classes that are too specific and not widely applicable. For example I could write a class to overcome the problem of wanting to join a local dataset with another with certain algorithms, but that would not be the solution to a simular problem. Actually You want to write a SQLHandle class which takes a SQL command applicable to ADO recordsets. Well go ahead, not my idea of beeing productive. Maybe a great idea for a software vendor trying to sell such class, but not for joe average just wanting to be productive.
>>Well, I'm not asking for every control, Better one or two, than none at all IMO. Get me the treeview first, the flexgrid and listview can wait a little :)
>You have my vote - still don't see it happening.
We can ask, can we ? If we don't ask, it will definately won't come.
>>Sad. There are still a lot of development languages doing ActiveX, and a lot of vendors still are doing and maintaining the ActiveX components I frequently use and only introducing the .NET variants (often a limited functional version) right now. A lot of those vendors do not like to be on the bleeding edge either it seems.
>.NET isn't exactly bleeding edge any more. It's been out for 2+ years now. And the .NET vendor market is filling out pretty solidly and pretty close to what the ActiveX marketplace for VB was at its peak.
I did not say that. The reason for them to take so long might have been, not wanting to be on the bleeding edge. A few of the controls I use Crystal Reports viewer, Leadtools, Pegasus are now offering .NET components. Some of them are still not as complete as their COM or ActiveX equivalent. Anyways there is not sign they are going to withdrawl from the activeX market.
>>In a sense I'd like to see VFP steering more towards 5GL, beeing a powerfull development platform with high quality RAD features. .NET currently is still a few steps behind VFP (You generally have to write more code to do the same).
>How so exactly? What do you see - something like PowerBuilder??? <g>
More towards a very solid development platform for creating huge frameworks of data driven and data intensive applications. Much like ERP/ERM packages are doing today.
>I don't see VFP being any more RAD than .NET from a designer view which I presume you mean by RAD. This will also change in Whidbey which will have much richer designer support for many advanced features.
I'm not specifically talking about wizards and designers, but just the language containing complex functions (e.g. the DML, like SQL).
>If we're talking about code - i'd argue that point too. Sure some things are a lot less code (SQL commands - but really NOTHING compares to xBase with its inline SQL commands), but beyond that this is not really true. Again this is solved easily with business/data tier objects that abstract that. If you do this (as I did in VFP as well as .NET) you end up with code that's not that different in each of the environments.
I agree, but my main focus is the integrated database engine. hence my comments.
Walter,
