>Of course I'm not interested in loosing all I love in VFP. If I was not clear enough (perhaps I wasn't) when I said "without loosing it's IDE", I meant ALL those goods we can have while in the command window.
>
>Also, I (strongly) don't want to loose it's data engine (99,99% of my apps are dbf oriented). If the price to be a part ot .net is to loose all that, thanks, I'll stay with the current version.

That's is probably one of the biggest reasons why VFP is not in .Net now.


>>Why would the resulting hybrid be any different than VB .Net?
>
>For the same reason that Delphi (in the net framework) will be different from VB.net (that's what I've been told).

I can't comment on Delphi as I have never used it. But having Delphi .Net, COBOL .Net, VB .Net, C# or VFP .Net that all do basically the same thing at the end (once compiled into the CLR and machine code, etc), it comes then as a difference in syntax. If VFP has to be in the CLR (or else it wouldn't be .Net) it will just be another syntax flavor, and one very similar to VB .Net, so what would be the point then?


>>What would be the point?
>
>Think it could be a way to position VFP in the frontline of developing tools, whatever that means, but IT goes a lot like the fashion industry, and now .net, C# is fashion etc (I know that'll be bombed for saying this, but that's ok), get some extra marketing, some folks that are thinking about leaving VFP could get extra motivation to stay with it, and the like. To me it makes no difference.

As I said before, if it becomes just another syntax in the CLR, why would people bother to learn it? VFP is only interesting because it is different than the others and because of its power. If it loses all that, I don't see much point in it. Can it be in the CLR and still maintain XBase and all it has to make it as good as it is? I'm not knowledgeable in its internals to say, but I doubt it.