>However, it occurs to me that the reason we may not have seen them may be that they can't be implemented without greatly increasing the memory footprint for the resultant applications and/or

Possibly, but we could always ask what the reason is?

>implemented without breaking existing applications.

The MNX and FRX is just meta data. I'm not sure how they would "break" apps. And the MNX is not compatible from VFP6 tp VFP7, so its not like they've never changed the structures.

>I do have one other thought. OO menus and reports are usually application specific and don't lend themselves well to re-use.

I have an application that I'm working on that has several hundred reports. Making a change to the standard header on those reports, or maybe, how the pages get numbered, what the Group headers look like, maybe standard footers would be a bear if we didn't come up with something nice. Report Objects and classes would be provide a standard, constitant way of doing that. Same as reports.

Consitancy is the main goal here. How do you set a checkbox to checked in a form? chkBox.Value = .T. How about on a menu? SET MARK. How do you set the caption of a command button? cmdButton.Caption = "Caption" How about on a menu? DEFINE BAR 1 OR sysmenu PROMPT "Caption"

How do you make fonts and colors dynamic in a grid? Just use the Dynamic properties. How about in a report? Hmmm, should act the same way, but it doesn't.

>It doesn't give us anything new except another way to do what we can already.

Then you totally missed my point :-)