Marc,

>1. to get VFP as a product closer to what MS, and the industry (quoting Jim B), regard as a mainstream product, would require no less than a rewrite.

Not at all, I think the point that George is making is not dissimilar to my own point, that modifying VFP (whether through a rewrite or any other method) to make use of the windows controls instead of tis won is what is needed to get VFP to play as well with ActiveX as VB does. However, doing that also takes away some of the uniqueness that VFP holds as a RAD tool for database centric application development.

>or 2. it are the unique features of VFP that, i.e. even if resources for rewriting would be allocated, make it improper as a mainstream product.

Mainstream is an interesting goal. Mainstream, to me, means in current vogue, which at one time xBase was. Today, xBase is out of vogue and VB is in. Tomorrow, who knows.

My point is truly only "be careful what we wish for", fulfilling certain wishes may be at the expense of other things. Contrary to many folks thoughts VFP does not have unlimited resources either in person power or money. Those resources must be used to the best advantage. That invariably means some stuff gets done and other stuff does not.

For example, in VFP6 we wished for better compliance with ActiveX and for OO menus, well we got the ActiveX improvement and we got COM compliance but the OO menus were left undone. Yes, I know that the COM stuff is not finished yet, but it is farther in VFP6 than it was in VFP5.