Hi, Ken.

>I don't think this makes any sense. First, VFP has over one million lines of C++ code (some C code), and re-writting it in C++ .NET would be a huge task, possibly over a year with no new features to add to VFP. Plus, having VFP be written in .NET means nothing. The Visual Studio .NET 2003 product is not written in C++ .NET, it is in C++. The new XML editor component of the upcoming Whidbey product is written in C# .NET, but that is one new component. The tool you use has nothing to do with the apps you build with the tool in this regard. What I'm saying is, this is a non-issue that is not worth considering or debating. It is more useful to focus on what tools and features you need for application development than the technical details of how tools are created. :)

Well, what I meant is that once the .NET Framework becomes ubiquous, running on top of the CLR would put a tool like VFP in another position.

Anyway, as you mentioned, I believe that the things make VFP great will finally get into .NET, and most of us will go on that way. I'm personally working on make this shift as subtle and painless as possible for myself, my team, and the community. I really wish that the VFP community, which is in my opinion one of VFP best features, will stick and become some sort of .NET Data community. I don't believe in a single large .NET community that can keep the same quality and "spiritual" relationship we all share.

Regards,