I've gotta agree with you, as far as developing new product is concerned - ON THE OTHER HAND, as a FP developer I was astonished when I discovered that all the programs and scripts created by the Paradox users in Accounting had to be completely re-written when they moved to a new release! Yech!

There is MUCH to be said for maintaining backwards compatibility, as there is for the related concept of allowing old customers to wean themselves to a new programming methodology at a reasonable rate. A lot of us need to be productive as we learn.

I think we all agree that it has been a long time since we've seen improvements in the Report Writer and Menu Builder, and other technologies in VFP (heck - many haven't changed since FPW2.x)! They're long overdue - and now that we've all been taken to OOP via VFP5, perhaps now (VFP6) is the time to drop some of the old baggage!

FWIW

>I'll probably get flamed for this, but this is in the spirit of John Petersen's post at the VBPJ forum...
>
>Everyone points to VFP's OOP as superior to VB's object based approach. But what about VFP's lack of a full component based approach to development, something I've only seen personally in Borland products?
>
>Look at VFP's "Main Window", Report Writer, and Menu Designer. These are left-overs from FPW 2.6! VFP 5.0 should have dropped these and other unnecessary hold-overs from the past to attract new blood to the product.
>
>One can spend a lot of time going through various properties which indicate that they are for backward compatibility. How about giving us a fully component based VFP without all the luggage to support procedural coding practices from the past? Why would anyone want to convert an existing FPW 2.6 or FPD app to VFP? The forms look better in the older Fox versions...
>
>Let me get my fire suit on...