John,

>So ? After 7 years VFP is still here and VB 6 down the drain. Did you ever wonder why Fox has a history of almost 20 years now? Do you understand its success ?

>There is still more VB 6 work today than VFP work. How do you define success??? VB 6 was replaced with .NET - it was innovated. The same is not true for Fox.

So? There Are more carpenters than bricklayers, so should we build every house out of wood? JVP logic here again. Of course .NEt was innovated, but what does that say about its application compared to VFP. Absolutely nothing. Again an empty statement.

.NET still could use some of the innovations that VFP had many years ago. So this is all relative. VFP did not have big innovations in the sense that it needed a rewrite. In this light VFP is build on a far more solid base (database technology) than VB in its time. And to be honest, I truly believe VFP still is build on a better foundation as .NET totally ignored the idea of integrating software development into database technology.

>If you really do, then you'd see the future, which .NET really is not at this moment.

>Well Walter....something can't be in the future...at this moment. Casey Stengel and Yogi Berra would be proud...

OK, Lets say that .NET is far from what the future of software development should be. (As outlined in this and my previous post).

>>New technology has to evolve. Sadly the new technologies often don't learn the lessons from the past. It is totally beyond me why .NET is not more integrated with database technology. You'd say they have some experience with VFP (to a limited extend) and with the aquisition of Navision they really should have a clue how software developement should look like in the future.

>.NET is extremely integrated. Your disconnect comes from the fact tha you are hard-wired to the way Fox does things...

Please don't comment on what you don't have a clue about. That .NET has a way of talking to a remote database system, does not at all mean that it is integrated. You can do that in C/C++ on the same level, but it still is not going to be a data centric language. Why are non of .NETs resources build on database technology? At least in VFP (though far from perfect), lots of resources like forms, classes, reports, the project manager, its OO model is build on database technology.

And no, I'm not even using VFP as a reference, but my experience with a certain ERP/ERM solution.
(Nice try). You see that is the problem with you, if someone does disagree it is always because I look with fox eyes. Tsss...

Won't you agree that having all project resources into one (SQL server) database would make sense ?
1. No files clutering up your HD.
2. Integrated source control
3. Multiple developers working on one project as easy as normal users accessing the database simutaniously?
4. Your application essentailly becomes a database.

Note this the mechanism lots of big ERP/ERM packages are using. Compare this with the pathetic way .NET handles its project management...

>>Again, qualify. A Callback function maybe? Well, you could write a fll and use that in VFP. There are more things in VFP that VB can't do than the other way arround. So please give me break.

>Raise and define events..... respond to windows events...... etc....

True, but is this a serious miss? I don't think so. You can write a fll, to integrate this into your VFP application if needed. Sure the VB is far more straightforward, but it is not impossible in VFP.

And after all, I don't think this is something you would need all the time in database applications. It is like saying: I won't use VB because I can't write assembly in it.

>>>After all this time, Fox still cannot fully interoperate with the Windows API.

>>Cristof lang has written the stuct class a long time ago to make things easier to integrate. You can always write a dll to overcome this issue. OTOH, you've got to ask what is the importance. Lots of API calls are directly supported, structs can be handled, but callback functions are a bit more difficult (you have to write a dll), but nothing is impossible.

>Well Walter, in our VFP 5 and 6 books, we developed a pretty good struct class. In fact, we have an entire chapter devoted to working with the windows API. In spite of good efforts, there are still limitations. For example, the only way to get a printer devise context is to use the common dialog control. In VB, you have direct access to a printer object.

Yes, and therefore we've got build in functions and 3rd party dlls to overcome the issue. Sure not all low level stuff is easy to implement, but you've to ask the question if VFP was ment for that? And does the average VFP developer care?

Compare that to the miss of a local database engine to do the datamunging and local data storage you take off from a VFP developer?

>>>nor can it fully support event-driven application development.

>>Examples please? It seems like an empty statement.

>Sure...lets say I have a report-server. If I had full async capability, I could send a message to the component, and then get notified via an event. In Fox, I cannot create custom events. And...while I can consume some events, I cannot create sub classes with events. It is an has been a big limiation for a long time. The record is replete with examples of this.

If both sides are VFP, you can. But again, you can workarround the issue. These examples are of little value in a database application environment.

>>>And compared to the state of the art today, its implementation of OO - while good in 1995 - has too many short-comings today.

>Like? While there are always wishes there are no big omissions in VFPs OO model. Please clarify.

>Events??? If you worked with VB - you would know...

Is that all you can think off? Raising and subscribing to events in VFP itself is implemented in VFP, and in some limited ways in previous version. Subscribing to COM events you can do with the IMPLEMENTS clause of DEFINE CLASS and the EVENTHANDLER() function, or using KenL vfpcom utility. Subscribing to API events can be done via a dll, or in the new function calvin is working on for VFP9. Again raising non VFP events is more problematic (though some can be achied with the windows API). You probably have to use a DLL solution. Would I like to see it implemented? Yes, A big miss ? No.

That said, your statment falls appart pretty quickly.

>You need to be careful Walter, you did a lot of slamming re: .net a while ago - when you clearly never used the product. Unlike you, I don't fall in that category...

Because you're (and some other audience as well) not able to look beyond the practise. You are not able to take a step higher in the abstractional view. You're not looking at concepts, structure, design paterns. I look at the big picture, not at every minor detail. The big picture of .NET is that its database integration is weak, and its design at the least doubtfull as the future lies in database driven applications (don't confuse with data driven applications). (you of course know the initial plans of longhorn..).

I know that VFP is not perfect either. As you outlined its integration in windows is weak on a number of areas. Absolutely true. But you fail to see that a .NET implementation has its disadvantages too.

You live in your own little world where you think that if you swallowed and grasped everything MS is trying to push down your throat, you know it all and have the authority to tell us what we should think and do.

It is like the carpenter who has build about everything, telling the architect with a vision how to constuct buildings. Short sighted and dumb. And like the carpented, you're too proud, ignorant to admit you're wrong, but are still hanging arround the architect for the sole reason to beat a dead horse and expect different results.

In every community we encounter these kind of wise guys who eventually fall off.

I can't wait.