Fons Rademakers writes: > > sound like a good idea. Could probably be implemented in such a way > that it is backward compatible (with a method like RecusiveAssociate()). I don't see why one needs a new method. Why not just re-write Associate()? Does it ever make sense for submenus to have different associated windows than their parent menus? > Would you mind to implement this and mail me this patch? I was afraid you might say this.... <grin> But, seriously, on thinking about it more, I think the problem is a little thornier. Consider this chain of events: 1) Create a main menu. 2) Associate the main menu with a TGMenuBar. 3) Some time later, try to add a sub menu from code which knows nothing about the TGMenuBar, so there is no way to call Associate() (recursive or otherwise) correctly. I think the only "right" solution is that when creating a (sub)menu one only needs to know about it's immediate parent, be that a TGMenuBar or another TGPopupMenu. I think this means that TGPopupMenu::AddPopup should call the recursive Associate() on the submenu being added, passing the current value of fMsgWindow of the parent menu. -Brett.
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:41 MET