Create New Desktop project.
Select Window1 in Contents.
In menu , Insert >> Event Handler >>>>> dialog “Add Event Handler to Windows1” Is displayed.
EnableMenuItems is not list.
what i want to do is
Listbox is in Windows1.
if RowCount of Listbox > 0 , menuittem “Save” enabled = true
if RowCount of Listbox = 0 , menuittem “Save” is enabled = false (user can’t select)
I wonder if the above processing should be written in Window1.EnableMenuItems event.
It does happen when the Menubar is selected. When you click on the File menu, for example the method is called and allows you to enable or disable menu items manually.
To reduce the amount of code that must be executed when a menu is selected. If, however, you are only going to get one event and then be able to move across all menus in the menu bar it has to work as it currently does.
Yes, that’s what it was looking like to me. That this should be the case seemed so unlikely that I assumed I’d overlooked something. I’m only displaying one menu at a time, so why can’t I be told which one it is?
Perhaps the OS doesn’t ask more than once per activation. After all you can slide your mouse over to another menu. If that doesn’t cause a new event then it would have to work this way.
Added a MenuBarSelected event containing system.DebugLog "MenuBarSelected called"
When I run it and click on the file menu, it logs a MenuBarSelected event.
If I then slide my mouse over to the Edit menu I get another MenuBarSelected event.
Sliding back to file, nothing happens.
Sliding to Application menu I get another MenuBarSelected event.
Sliding to either File or Edit nothing happens.
It would seem, at least on the Mac that:
MenuBarSelected is called for each menu that is activated.
It is only called once per menu until choose something from the menus or hide it.
So it would seem to be a benefit to know which menu is being shown so you can activate the settings for just that menu.
That may all fall apart on Windows or Linux, but I don’t currently have a way of testing that.
Yes, because it’s nowhere near as good of a name as the original. The purpose of the event is to EnableMenuItems so yeah, it will fire when a different menu opens.
Or, like drawing in Paint events, you could do just the enabling code in the event – like you’re supposed to.
You’re honestly just over-engineering the silly API 2.0 rename. The menu systems in place work and have worked for as long as I’ve been here. If you’re doing long computations in the EnableMenuItems event, that’s a your-code problem.
Not quite sure what your point is. Our point is that we’d like to know which menu is showing when the event fires. That way, we can set up a nice select in the event handler and segregate the code to enable/disable each menu as required. Then, less code is executed at each firing.
But I suppose it’s possible that such a scheme is not completely reliable, thus forcing one to run all the code for all menus, each time.
There’s not a heck of a lot you can do about the selected menu. Notice that none of your timers are firing and the UI does not update when a Menu is open.
I don’t want to do anything about the selected menu, other than enable/disable menu items based on the state of the app. What else do you imagine I might want to do?
Frequently in this forum threads get derailed after they have been solved (sometimes certain individuals don’t even wait that long). The discussion that occurred after you got your answer was about a proposed idea to complicate the MenuBar system.
The event you need and were looking for was the MenubarSelected event. Hopefully our discussion didn’t confuse you on this matter. I apologize if it did.