>If I was to build another generation of framework, I wld consider
>treeview as replacement for system menus! If you ask me VFP Menus are 'so yesterday' comparing to other tools/products. But yet they are quick and precise and users are comfortable with them. Nothing ever 'dissapears' from there :)

That's what I've done... in 1997 (VFP5!), for exactly the same reasons. I've even done one application using it, a couple of years ago, even though the rest of the (port of the) framework was not exactly finished. And it was data driven, from menu.dbf - which is the same old table which we used to drive menus back in 1989, with a few changes in the structure and a recursive bit of code which parsed it and built a treeview from it. Want the code?

In FPD2.6, the forms were modal by nature, and there was no reason to collapse the menu once a bar was activated. You couldn't see the menu once you opened a form, anyway - it would be covered. The 80x24 world gave you not only claustrophobia, but the added benefit of the menu which waited for you to close the form, so you knew where you were.

Windows changed all that, and that, IMO, sucked. With every new application, specially in the first ten years before stuff got more or less standardized, anything that had more than 100 features presented a huge problem to the user: where the the is this in the menu? And collapsing menus made it only worse - you found what you were looking for, but couldn't find it again. Office 6 and later only helped you lose it by hiding menu bars you used less frequently, and worked generally in favour of your next heartburn.

>How good you can control/coordinate treeview with keyboard would be my main
>consideration.

You definitely want to see the code :).