And I had such great hopes for it, too. I bought I think 6 books on it when it first came out. After reading the first one and half of the second, and then skimming the rest, I had a great sinking feeling, as in, "OMG, they really don't know what they are doing when it comes to building complex business applications." The great Stored Procedure for data operations blunder (the SQL gurus had been preaching for at least 5 years before that on the need to offload processing to the client) is the smallest part of it, but typified the problem: grasping in a naive way for a solution because the language was so limiting. Eventhandlers in order to program event-response: true, VFP probably did that under the hood, but why take that step backwards? On and on from there...

OTOH, having the .Net resources is wonderful -- if you can access them without jumping through hoops.

VFP.Net would have solved all these issues. And it may still (if they produce the final updates), but whether it's commercially viable remains to be seen, and depends on how eTec proceeds once it has a product.

Hank

>To say that .Net works, however, leaves out quite a few details. C++ works, too. So does Assembly. The issue isn't whether it works, but whether it is tuned to the work we actually do. I think I've made the case here and in my blog entries that .Net in it's statically-typed form does not meet many (and certainly does not meet my) development needs in creating and maintaining large, complex business applications
>
>
>The above statement is why I have not moved to .Net - it sucks at what I expect a language to do for me.
>
>Johnf