>That's not a bad idea, but I think ADO improvements are probably more likely.

I'll keep lobbying... :-)

>And exactly when was the last time you had to deal with that? I think for me it was about 1995. Besides, even if I needed it now I'd probably just generate a menu and cut and paste.

I do SET CHECKs all the time, and the SKIP FOR bothers me big time. If i had some properties it would be way easier...

>Further, we be added more to "...included for backward compatibility" heap.

I don't see that as a bad thing.

>What's the matter, footprint not big enough for you?:-)

Hehe, good point.

>Very nice, very OOPy, and what kind of overhead are we looking at? This type of stuff doesn't come without a good deal more than we currently have, I'd imagine.

Maybe. I also think it would be cool if each Form had a menu property where we could create the menu of a form there, and pass menu objects around from the screen to its child forms would be cool too.

>I wouldn't say we'll "never" get it, but right now, I can't see where "the view is worth the climb." How about multiple inheritance? FWIW, I can see report objects and how they'd be beneficial, but menus I've a bit of trouble with.

I think it all has to do with creating a complete, modern language. For you and I, yeah, VFP is cool, we've lived with the Menu Designer for a while. But trying to get new users to use a lanugage full of DEFINE BARs, or strange SETs, and especially all the SYS()s, they'll probably want to choose a newer language.