Hi Rick
>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.

>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...

Code often gets reworked, sometimes with regular budgets well into 6 or lower 7 digit sums - and I am definatly more often arguing against a complete rewrite. Working code has *much* more worth than coding costs alone - the cost of pure development ranges between .15 and .25 on seven digit projects. But planning to rework applications where it is *uncertain* how well their runtime works in the post-Vista windows versions is definatly getting more complicated. While I do believe vfp will run as a 32 bit app even a purely technical risk assesment is difficult, and most of these discussions are not entirely<g> based on technical arguements.

Even if factoring maintainance cost to be higher on "legacy" systems I almost always can deliver much more bang for the buck by working off the existing codebase: something like 2/3 of the intended functionality at 10% of the cost and at least half of the increase in maintainance cost due to "legacy weakness" eliminated. Variations can be expected due to existing code quality as well as number and level of coworkers on the project<bg>.

As the ETec compiler is currently not finished and I have not tested tools for automatic conversion from vfp to .net this is hypothetical, but I would prefer a vfp/.Net compiler to an automatic conversion given they had similar levels of robustness, language coverage and so on.

The elimination of J# and Delphi's uncertain future definitely gives more weight to the arguments against "JAL". But a hungry small company might produce something making business sense to use - even including bleeding edges we are currently better protected against as MS *is* well established.

Creating single layer apps in a vfp alone is not best practice in my book, and doing so again in a new vfp/.net compiler by a small company would be even less. But such a compiler could give interesting and worthwhile refactoring options - even if the bulk of the app is still kept in the vfp-syntax.

And yes, much much hinges for me on the implementation of the table layer *and* the possibility to work from the command window - even down to having Ironpython as noted fallback option. But that also is partly influenced by my current main gig and a large dose of personal preference.

I guess there is more than even chance that ETec can produce some biz value for me and also more than even chance any conversion tool does the same for a large conversion task. In my personal opinion the chances of resurrecting MS-vfp/open sourcing the runtimes and all the other currently very active topics are practically zero: why not put at least the "flame energy" into something more constructive ?

my 0.02 EUR

thomas