Thomas:

I think the allegory limps a little for the purposes of this discussion. If you switch from an Olds to another make, you don't have to learn all new user controls...

Going from a stick shift to an automatic is easy. Going the other way is harder. The worst case scenario: You buy a car meant to be driven in Britain or Japan or Australia, and you'll have to adjust to a relatively minor UI change of the steering wheel being on the "wrong" side <g>. Everything else is ***exactly*** the same.

Pertti

>Fred;
>
>Well, companies have been known to make business decisions. Take GM for example: Closing down the Oldsmobile division was a business decision. Some people like Oldsmobile’s but I do not think that GM would be interested in how some customers feel.
>
>Olds began in 1897 and was the third oldest automobile manufacturer in the world. My first car was an Olds and I loved it. VFP is a great tool, but like cars, there are other viable options to choose from, when something you like disappears from the scene. :)
>
>Tom
>
>
>
>>Rick,
>>
>>I almost totally agree except for one major point. While you can continue to run the existing VFP for some indefinite amount of time on current harware, what happens when future hardware/OS software (several generations maybe) prevents that from running? That's when I see the "value" of all the existing code being completely discarded with no alternative except to re-write in programming language flavour du-jour. For larger operations, this is a huge expense, though they can probably survive it (not sure considering how much COBOL code is still being kept in production at that level). As far as some smaller to middle size operations, there's no way they can afford to convert their code base and remain in business. Pretty unfair that Microsoft can wield that kind of power on a marketing whim, don't you think? The smaller operations are probably even more dependent on some of their Fox apps than Microsoft realizes.
>>
>>
>>>Fred,
>>>
>>>I agree.
>>>
>>>But again if you look at your existing investment of code that code isn't dead. It can continue to run and it can be accessed externally.
>>>
>>>Also remember that 'developer value' doesn't go away at all. Your skill set with Visual FoxPro and the business knowledge will serve you very well with anything else you might try your hand at.
>>>
>>>And if it really comes down to leveraging existing FoxPro code - you can also still do that via COM. Just about from anywhere is your FoxPro code accessible if you really can't live without it although I'll be the first to admit that this is suboptimal...
>>>
>>>+++ Rick ---
>>>
>>>>The point here is not that new code could be written in whatever language with only minor syntactical differences, the real attempt here is to not lose the entire value of the millions of lines of existing code. This is something that Microsoft seems to "forget" at every level when a new version of their products are brought out. Ever have Excel or Word macros that broke between versions? And how about even their versions of the C compiler and MASM? VFP has been very good maintaining a pretty solid "backwards compatibility" considering the very different philosophy of Windows programming vs. DOS programming. Is 100% of the code transportable? Of course not, but it all wasn't disposable, either.
>>>>
>>>>
>>>>>I hate to be a naysayer here, but 'what's the point?'
>>>>>
>>>>>Assume for a minute you could indeed duplicate the full language and make it more or less work the same as VFP. What do you gain?
>>>>>
>>>>>The real key and really the only feature that VFP has that .NET lacks is native data access language to run dynamic inline SQL and Data commands and access local cursors. Nearly all of the rest is just minor syntax (with the exception of evaluation and dynamic execution which likely wouldn't work without runtimes either).
>>>>>
>>>>>No matter what you do you are likely to loose that functionality with any compiler's/tricks/workarounds. Without that what do you really have? Just another language (JAL) in .NET that isn't any better suited to deal with everyday programming tasks than is C#/VB etc.
>>>>>
>>>>>Whether I use a function like your Between or overloaded versions written in C# code (which would be more code but not much) what does that buy me? Very little.
>>>>>
>>>>>To do this right a lot of work would need to be done along the lines of IronPython (dynamic language support for .NET) to provide the untyped/duck typing approach that VFP uses and more importantly it would require a local data engine and full SQL language parser to get the DDL stuff to run along with a local cursor engine.
>>>>>
>>>>>The latter is no trivial task as Microsoft is now finding out as they are building LINQ and DLINQ and trying to shoehorn a dynamic syntax into a static language. There are many, many gotchas and tweaks required to make this work and that is really the key feature that .NET has been missing IMHO.
>>>>>
>>>>>All the rest is negliable... VFP is a nice all around language but the only unique feature (to xBase) is the sql data language and local cursor engine. Take that away and you have an average environment that is not anything special over other tools and getting up to speed is a matter of syntax.
>>>>>
>>>>>VFP is a great tool - if you want to use it, continue to use it. It's not going to die out over night with official support way off in the future.