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

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


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

>>And if that is not bad enough, there are things Visual Basic could do 7 years ago that made life easier that Fox still cannot do today.
>
>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....

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


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


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

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

John