>>>Lets look at .NET. I did see significant improvements in the data handling over the years and there certainly a lot going on in this respect for future versions. As long as that happening it has not matured yet. It took up to VFP6SP3 or VFP7 for VFP to be matured.
>>
>>When did you start using VFP? Is it when VFP6SP3 and above versions? I started using VFP 3.0 and accomplished a lot and did some improvements per releases... And my apps matured hand in hand with the VFP as a language.
>
>I never used VFP3 for anything. At that time I was programming in FPW/FPD2.6. A colleage was doing some experimentations with VFP3 and it behaved like a pig. I started something simple in 5.0, but it was not until VFP6SP3 when things got serious. I did however, keep track of all VFP versions at that time. Did do a lot of reading and testing.
>
>>>>And if you will wait for .NET or other tools to mature to your liking before using then it will be disastrous in the end
>>>
>>>Why?? I can't see that. Jumping .NET right now will be disasterous for the project I'm working for right now. Too much (meta) data handling on the client side. At least the LINQ and SSCE thing need to be matured. Can you explain? If its about experience? Not an issue. We work in a team. If we need .NET experience we can buy .NET experience.
>
>>I think waiting for a product to mature before using it is much like a coach waiting for Michael Jordan to mature before using him to play in the hardcourt. How could it be?
>
>I don't agree. It is not that I'm specifically waiting for VB.NET or C# to mature, but the number of viable options grow (IOW, the .NET platform to mature). It does not make sense to make the wrong decision too early in the game. Currently I've got seriously workarround the limitations. I don't want to rewrite the app again when a clearly superiour method comes along (Again LINQ, SSCE). It does not make sense at all. It is a wast of my time to get frustrated to workarround issues that are so basic to me.

In our case, while we are already using .NET, the VFP app version is still being updated from time to time but we already started rewriting it portion by portion.

Maybe we should agree to disagree on this matter because your situation is different than ours. We also work as a team here only that one team for the .NET and another for the old version of our app using VFP 9.0.

>>One of the reasons why we don't get another version of VFP is that it's already matured. It reached its ceiling.
>
>I do not agree. They could have announced a .NET version including all features like the local database engine. Further, there is a huge wishlist open for VFP10. Optional stric typing is one of my favourates.

I maybe wrong on that one but that's one the reasons why. Surely VFP have still rooms for improvements but if it is likened to a building, it can accommodate room extensions but can no longer accommodate additional floors.