J.

You *do* like to sir it up every now and then, don't you!

I think many agree that the main window, report writer and menu designer could use improvement. Hopefully, in less than 10 days, we'll all be hearing of nice changes in at least some of these areas.

As for the backwards compatability. . . while I would say they *do* add complexity and confusion to the product, not to mention different peoples' interpretation of just what the 'included for backward compatability' actually means, they are a NECESSARY EVIL.

Where once there is reputed to have been about 3,000,000 FPD/FPW programmers, all those people couldn't just be left hanging while the world moved on. IBM did just that in the 60's and learned the lesson that they had better NEVER EVER do that again.

Frankly, you have been looking for any excuse for *NOT* adopting VFP. Why not just make a "management decision" and do it??? It really does look like you simply will not make any kind of decision, though your mind is quite obviously made up as far as VFP is concerned.

Once again, this *IS* meant to be helpful.

Jim N

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