Basically, I would like to check/uncheck the “Show simu.hits” entry (see attached image). Since this entry has a cascaded menu, there is no way (as far as I know) to retrieve the entry id (fix to -2 by default) and then apply check/uncheck, hide/unhide even enable/disable methods.
I think this makes sense to be able to check/uncheck the “Show simu.hits” to show or not this kind of hit category and inside this hit category, to be able to change the way to show these hits.
I think this is actually not possible as discussed in [url=https://root-forum.cern.ch/t/how-do-i-hide-a-tgpopupmenu/3810/1 related topic[/url] where Ilka explained why such change is disfavored by some rules. So I “hacked” part of the TGPopupMenu (AddPopup and EndMenu methods) and I know it can be done. To make it less intrusive, I also follow Valeriy’s suggestion to create a derived class of TGPopupMenu but, as Valeriy said, TGMenuEntry members are protected and since no “setters” exist it is impossible to change the default behavior of TGPopupMenu through a derived class.
So my question is the following one : does the ROOT GUI still has to strictly follow Wilbert O. Galitz’s rules ? If yes, is it possible to add some setters to TGMenuEntry class to let people implement their own “TGPopupMenu” derived class ?
Thanks in advance
We may consider making changes i the GUI, if it makes sense and can help other users. So feel free to ask which setter/getter(s) you would like to see added, or even propose a patch implementing your specific needs and we will be happy to evaluate it
Reading again my post, I’m not sure I was clear about what I have done. What I achieve so far is to hide a cascaded menu by adding an ‘id’ into the AddPopup method. Something like that :
virtual void AddPopup(TGHotString *s, TGPopupMenu *popup,
TGMenuEntry *before = 0, const TGPicture *p = 0,
Int_t id = -2);
I add ‘id’ at the end of the method to not screwed up calls of this method by other part of the program although this declaration breaks the consistency with the AddEntry method where ‘id’ is the second argument. Anyway this is a detail.
Implementation of AddPopup method uses of course this new parameter and then one can use HideEntry(id).
Next step was actually to try to make my own derived class of TGPopupMenu to (re)code part of the EndMenu method to be able to check/uncheck the “Show simu. hits”. So far, I am still thinking on how to do that (the “hiding” exercise was much easier ), but, for such (personal) purpose, I would need to set member values of TGMenuEntry and thus, I will need some setters in the TGMenuEntry.
Fine, so just let me know which “some” you need and I’ll be happy to add them.
Actually if someone wants to redefine the AddPopup method of TGopupMenu, he needs to have access to almost all TGMenuEntry members i.e.
Int_t fEntryId; // the entry id (used for event processing)
void *fUserData; // pointer to user data structure
EMenuEntryType fType; // type of entry
Int_t fStatus; // entry status (OR of EMenuEntryState)
Int_t fEx, fEy; // position of entry
UInt_t fEw, fEh; // width and height of entry
TGHotString *fLabel; // menu entry label
TGString *fShortcut; // menu entry shortcut
const TGPicture *fPic; // menu entry icon
TGPopupMenu *fPopup; // pointer to popup menu (in case of cascading menus)
So having setters for all of them will be nice (maybe a TGMenuEntry constructor with part of these members as arguments can also help in such way that not all setters have to be defined).
If you can do that… thanks a lot,
I’m a bit reluctant to blindly add setters for all class members. Couldn’t you simply tell me what you actually need? Or just implement you derived class, adding the missing (needed) setters to the TGMenuEntry base class and send the diff. But if only the fEntryId setter is needed, I can already add it now.
As you suggest, I created a derived class of TGMenuEntry in order to add dedicated “setters” to TGMenuEntry members. I think it is much better because it is not intrusive and for my project I can then fully rewrite the AddPopup method.
Maybe the SetId method can be useful to someone else (especially for hiding [url=https://root-forum.cern.ch/t/how-do-i-hide-a-tgpopupmenu/3810/1 menu[/url]) but for what I need to do, I don’t have to use it. So, thanks again for your prompt help and advice ,
You’re welcome! Glad to see you solved your problem. And anyway, feel free to ask if you need specific changes in the GUI. We are always open to suggestions, as long as we have concrete use cases and assuming it can be useful for the community.