>And if you would like to take the 2nd position, would you like people to have additions made to the VFP10-wish list? Is it a good idea to make an Etecnologia-chapter on UT? etc. etc.

Give them time to finish a vfp9-compatible version first ;-)

In the article it is mentioned that

about one third of the commands and functions is implemented

funding for more developers might be a problem

SQL is a language in itself
perhaps defining in between steps is a better help than rasising the bar.

I myself would pay for a "backend part" only, consisting mainly of all the functionality found in the FPW/FPDos versions:

albeit with Select-SQL on the level reached in vfp9,

all xbase functions found back then impelemented with all the vfp9-level-functionality

? and wait window - support

but without ANY other GUI support from that area - neither @say get nor menu <g>.

from current versions support for

local,

candidate keys,

table/cdx-functions like key(), ataginfo, afields()

declare DLL,

the empty class (with scatter/gather name)

one class like custom for OOP programming paradigma

perhaps more current string and array functions (alines was the first thing I backported to FPW <g>)

The next step could be a "business layer compatible" level, with support for eventbinding, timers, collections, datasession, SOAP, DBC, all other SQL commands and so on: everything NON-GUI.

The last step would be a GUI-enabled version - after that enhancements will be asked for.

Probably the priorities of others will be different <bg>, but such a stepwise implementation should make sense to everybody creating layered apps and a similar approach could perhaps get some funding back to ET...

my 0.02 EUR

thomas