>>"Burning the VFP Team's resources" is a problem of mine???? Does that mean that those responsible for the selection of "features" to add to VFP6 are now in purgatory or elsewhere?!?! Making and maintaining a VFP.NET in addition to regular VFP might be a huge job or it might be a piece of cake. I have no idea.
>
>It would mean sacrificing features forever. If you add a feature to the non-managed VFP, you have to add it to the managed code. This means twice the work as long as both versions exist.
>

AT LEAST twice the work; where adding or extending functionality on one side of the fence might be a piece of cake, on the other it often would be a bear, just from the perspective of how the variable space and execution dataspaces are managed. I look at the difference in headaches between passing a SafeArray by ref to a COM object vs passing a ref to a SafeArray in a structure, and shudder to think what the code base would look like with both managed and unmanaged code, with two radically different philosophies of interpreter behavior. Learning a second language (which to me, much like Mike, is pretty much a matter of changing flavors of ice cream) in exchange for a viable, functional, fast VFP with continued backwards compatibility for the dinosaurs who still want to use @...SAY...GET < g > seems a small price to pay compared to how heavily the relatively small resources of the Fox team would become fragmented supporting both environments.

>>
>>>We'll never have time to add features to the report writer if we had to compile to the CLR. (Disclaimer: the previous statement was an attempt at humor. Call it sarcasm, call it facetiousness, call it what you will, but it implies no promise of any new features for the next version of VFP.)
>>
>>My main point is that people who are intimate with VFP will naturally ask for a .NET version rather than simply accept that the have to LEARN another language. Is it so hard to grasp that people who worked hard 'getting' the subtleties of VFP don't want to spend an even greater amount of time learning the same for yet more languages and facilities???? Is it that hard to grasp that people do not want to be in the 'minimally capable' category for expertise in a language for years to come? Especially when we have much of the real object orientation (and its concomitant constraints) that is proving so bothersome to the VB folks.
>

We have too much of the population of VFP developers with marginal skills with VFP; imagine the uproar when MS comes out and says "Guys, everything you know is wrong..." - we'd lose another sizable chunk of the community, especially the ones still in the legacy market support environment.

>I disagree. I do not want a VFP .Net. Many others have expressed the same thing. It was very clear last year at the Miami DevCon that the Fox community did not want a VFP .Net.

Count me as a vote against VFP.Net; C# roolz < g >