I must agree... there are NUMEROUS wish list items that still have great merit, not to mention the perennial tables/files greater than 2GB.

Maybe when the 2GB limitation is removed then Microsoft ***might*** have a small part of a leg to stand on as regards utility of VFP in the future.

As regards there being a "nice BIG window for VFP developers to learn other...", that's possibly 'nice' but it actually has NO VALUE as regards VFP and its viability for the future. And there is the aspect that more and more shops, especially of the small/mid size variety, are sick and tired of being pushed around by MS and their unpaid agents (developers who always push the latest and greatest) and just want to keep having simple and quick and accurate systems that work.

Finally, it is said often that .NET is having 'better data capabilities' added to it.
Seems clear to me that VFP is the clear and obvious way to achieve this...
1) VFP as native .NET
2) C# and VB.NET with capability to access/process/update data from such.

cheers


>I don't think anybody is having a problem understanding this. I think the original post was a statement about why there may not be a new version of VFP which is a very worthy topic of discussion, imo. The statement that "there aren't enough new ideas for VFP" or even "there aren't enough upgrades of vfp" to justify another version are extremely debatable subjects although it may not matter since MS has it's own agenda anyway. I would just like better .NET VFP interop examples from MS. I think a lot of developers don't want to be forced to rewrite VFP apps in C# or VB.NET, but, probably wouldn't have a problem using them in conjunction with one another and, possibly, do a gradual migration. You'd think that MS would like this too since it would mean the purchase of VFP9 in addition to the latest VS.NET...
>
>>Why is it so hard for some folks to understand that MS is providing a nice BIG window for VFP developers to learn other technologies? In particular, .Net.