>But I'm not a fan of all the PAD, POPUP, Bar visual classes. Also why two class libs the amenus and atmenus ?? I can see that a moderately complex having 100s of visual class objects for menus, that seems like a nightmare to keep track of, especially when it seems most of the time 1-3 attributes are being set and few methods ( click for example ) have concrete code, jumping back and forth between objects IMO is a pain.
>
>Therefore I just moved all of these visual classes into a PRG. ( I may split the PRG into one per major menu group ) I still have all of the classes but they are now in one easy ( for me at least ) to deal with place.

I didn't go to quite the extreme you did, but did some major shuffling of menu classes to satisfy myself. Now, cmenus holds the base classes, ctmenus is empty, kmenus holds the predefined pads and popups, kmenubars holds the bars. A* versions hold the app specific versions. Why the split between pad+popup and bars? Just logical, IMO. You never(okay rarely) have a pad without a popup, and you can often move bars between popups. Sure it's an extra few seconds to open two classlibs when I'm defining a new menu entry, but to me, it's worth it.

Chris.