>>After looking at the differences between FoxPro and other languages, as shown on MSDN, I now think there is some real value in porting VFP's language elements to the CLR (of course, the data engine is out of the question).
>
>Can you give some examples of what language features we need?
>

Hmmm... "need" isn't the word I would use. I think the whole point of supporting multiple languages in .Net is so that a developer can use the language he prefers or is most familiar with. Otherwise, Microsoft would tell us we all have to use C#. Based on the simple examples at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/html/vxgrfLanguageEquivalentsCodeExamples.asp , I preferred the VFP code in most cases, although they were all very similar. I'm sure that is in part because I am most familiar with VFP.

Off of the top of my head, I compared VFP's array functions to those in VB.Net. The VB language offers very little in comparison, as most of the functionality is in the .Net Framework. (I'm not a VB developer so please correct me if I'm wrong). VFP is a very feature-rich language, which is probably part of the reason it doesn't fit into the .Net mold. Wouldn't it be of value to VFP developers to use ACOPY(), ASCAN(), and other language functions that they are familiar with (especially those lovely SYS() functions <g>)? Again, correct me if I'm wrong, but I assume to some extent the VB.Net language includes functionality from VB6 that might otherwise be handled in the .Net Framework. Why not do the same with VFP?

Like I said in my last message, I hope this doesn't happen anytime soon. But if the time comes to transition to .Net, it would be nice to have the VFP language there.

>>I wonder if VB developers use ADO recordsets to data-drive applications? It doesn't seem as appealing under those circumstances.
>
>I dunno, one possibility is XSLT with XML. For example, I wrote a thing called FoxMessenger that I built this menu system for. The menus are compeltely XML driven, so if I get some XML from a Web Service, I just XSLT that to look like menu XML and pass it along to the menu system and it gets built there.
>

That sounds like a good idea, and probably less resource-intensive than ADO.Net.