Activate a menu item from code

I have a number of menu handlers that are fairly complex and it would be nice if I could activate the menu item from code. However, I cannot figure out any way to do that. Is this possible? If so, how do I do it?


You dont

I’d move the menu handler code into a method
Call the method from your menu handler & from where ever else you want

[quote=328392:@Norman Palardy]move the menu handler code into a method
call the method from your menu handler & from where ever else you want[/quote]

Thats what I have been doing, but most of the handlers call multiple methods, and I was trying to keep the number of additional methods down. Is there some fundamental reason we could not have a command such as,

or something like that? If that is possible, I will file a feature request.

FYI its been requested and rejected before

Call a method

Ok, but why was it rejected? I am just interested.
To save time, feel free to select from the multiple choice list below:

(a) It is bad form, and makes code harder to read.
(b) It is too hard to implement.
© A good programmer would know better than to request it as a method will do just as well, so stop bugging me.

Thanks for all the fish!

It would simply add syntax to do what is already possible by calling a method
Basically its not needed

You can submit an FR but I wouldn’t hold my breath about it since the “workaround” is so simple

Isn’t this what EnableMenuItems is all about?
enable or disable menuitems based on conditions existing at the moment the user touchs the menubar.

Or are you wanting to emulate the menuhandler? if so, then what Norman suggested is the correct way to do it

as a matter of design, all my menuhandlers are TWO lines of code

call something
return true

I think its a bad practice to put the code in the menu handler… best call a Method, as suggested. That way you will enjoy more flexibility too, as for example providing the same functionality from two UI items (something that is very common): the menu item and maybe a contextual menu or another window control.


I don’t know if I’d say it’s ‘bad practice’ to put things in the menu handler because there are times you’ll only have one place/way to call the menu handler. About window, preferences, etc tend to be that way. However, as soon as I have to call it from another location I turn it into a method.

So if my Preferences window needs to be opened outside of the menu handler I create a method for it. I also tend to call them “HandleSomething”, so in this case it would be HandleOpenPreferencesWindow. But that’s a personal preference (pun not intended) and you can name it whatever you want (just be consistent).

I did not know in 15+ years of using quite naturally menu handlers in app or windows, I was indulging in bad practice.

Sounds to me just as far fetched as saying that using build in event handlers versus addhandler is bad practice.

Fact is, in all those years, I designed my apps to do without the more complex and less direct method approach.

AddHandler has, in my experience, been the source of so many weird bugs (both in the IDE and in users reports with projects attached) that I would tend to avoid it as your project gets larger
I wont go so far as to say “single handedly the source of most bugs” but it definitely makes tracking down weird bugs VERY difficult
I’ve even given a couple really nice examples of it on another thread

But what do I know - the IDE is only 180,000 lines of Xojo code :slight_smile: