Hi Johan,

>Hope this is of interest to some

Of course it is:-)

Most of VFPers came to VFP for the speed and usabiliy. Which was unmatched when it comes sheer database mangling. Until a dozen of years ago, when VFP database sizes became limit for a lot of us, there was no better tool to interactively investigate data.

The ability to produce a code-based application that would compound the result of these data-massaging actions (dbfs either locals or as SQL-engine downloads and then, on a second step, local rushmore-sped-up local sql command) has been a joy to work with. But sure VFP is now showing its age now:
- UI interactions are stuck pre-dotnet area (except if trick it with "legacy" activex or dotnet bridging code),
- the power little engine is stuck in the single-thread 32bits arena,
- the speed of the interpreter is on par python. But yes that's interpreter speed, and C++ speed improved are NOT simple (fll).

"Premature optimization" is definitely NOT a VFP way and part of its great success back in the years. Yes a lot us are all followers of Donald here (Knuth edition...).

So yes, I definitely appreciate your bits of code. And that would be great if XSharp could be the place where where we could have a relatively benign dotnet compiler with an environment as dynamic as possibly later - not earlier - access to the usual speed improvements via type declarations.

On the same line, having a fast and decent way to produce declarative UIs reasonable fast and then later on move the GUI stuff to WFP when appropriate would be great. I am certainly pushing the enveloppe a bit here. But we are on a forum aren't we :-)

Daniel