>>Riiight. What seems would be 1000 times better would be if VFP wasn't using it's own controls and forms anymore and used the .NET controls. I mean allowing VFP to make calls directly to the .NET Framework from within VFP seems like a good idea - but as a developer I wouldnt waste my time - I'd just save myself the hassle and ditch VFP all together - which obviously I don't wanna do.....or give up on MS doing it and write my own flavor of foxpro that uses the .net IDE - which again I'm not excited about doing because it'd take me freakn forever.
>
>Well, what you're basically asking for then is VFP.Net which as far as I know was decided against a long time ago by Microsoft and also most developers.
>
>And I would agree that this would not anything all that useful.
>
>My question to you is why would you want to do this? If you need to call Fox code today from .Net you can do that. If you need to call .Net code from VFP today you can do that. WHat else could you really want then short of a full .Net version of VFP?

Yes you're right, fox code can be called from .net and visa-vera. My concern isnt so much of a technical nature as it is a practical one. What it boils down to is the simple fact that since there is no VFP .NET how the heck are you supposed to convince CLIENTS (you know, the people that pay my bills and stuff) to use it? I can jump up and down and point to 100 web pages that say 'yeah, its the right tool for the job' but there is no hiding the fact that compared to VB programmers our numbers are small. Clients worry about the 'run over by a truck' syndrom (lost developer) and what are the odds of finding a local VFP guy as opposed to a local .NET guy? What about 3rd party tools and gizmo's and stuff? There are already more .NET toys than there are VFP toys and heck it just came out! It's a compatibility issue. Sooner or later I'm gonna be standing in front of my clients feeling like a clown trying to tell them to use VFP when everyone else in the world is saying otherwise.