>>- Better ADO support, primarily the ability to bind all controls to a recordset.
>Yes, yes, yes. I'd hope so.

I'm still behind the idea of a table object that we can specify comes from a DBF, a SQL Select statement, SQL Server, or an ADO record set. We would use the table object the same way accorss the board, binding it to controls and such. That would be better than anything ADO specific.

>>- OOP menus
>Dubious. Here's how I feel. First, menus are pretty much application specific, so what would we gain?

A way around the clumsy DEFINE BAR stuff.

>Second, the LIFO stack implementation of VFP menus is a very powerful construct already.

What about setting the visible property of a menu pad to .F., or taking the object out of the menu object storing it in an App object for later use as a menu. What about inhertiance between Menu popups and Short cut menus? How about creating an XML version of your objects, sending them to a browser, and doing some XSL on it to get an HTML menu? The designer could be better too, have a WYSIWYG menu designer where you can set the checked property of a bar and see it in your designer. Very handy.

>Third, and perhaps most telling, menus aren't even objects in VC++, they're resources.

It doesn't mean they can't have an object interface in VFP.

>I think we'd all like better docs.< s >

Just add the Hacker's guide CHM to the menu bar ;-)