ok, I'm almost catching up with my pending messages..... :)


>>But being able to use VFP command/function syntax with a local data engine would be very nice for a VFP programmer even if they did have to start strong typing their variables. The truth is that several other languages are being ported. I dont think this is a technical issue as such but rather a financial one. I'm not an expert though so its only a 2 cent opinion :)

a local data engine in .Net in the way we know in VFP is not gonna happen, mostly because of (again!) strong-typing. In VFP we do something like:

var = Customer.Phone

in .Net that would be a weird beast because Customer.Phone should be either Object.Member or Class.StaticMember. In order to achieve something similar to VFP's cursor, a Typed-DataSet would have to be used.

Something I definitely miss in .NET though is VFP's own subset of SQL.

I agree with you that if MS decided to spend money on making a VFP-like language for .NET, there probably won't have technical problems. However, that would be such a small market that no company would even try that. Ok Ok, there are some .NET languages that we haven't even heard of, but my guess is that they're doing this because that's their only way of living, so they're better off jumping on the bandwagon. In Microsoft case, VFP is not what keep their business, so I guess they just prefer to tell VFPers about what the other options are.

I might be wrong, but, that's just my 0.02 cents anyway.... <s>