User events for menu item selections

[Intaris]

Something which I have found annoying over the years is the fact that ALL user menu selections trigger the same event.

I often lay out a nice event structure for UI handling with functions arranged nicely within the event structure and then have to start messing around with strings and Tags in one big case structure in my event structure in order to be able to find out what just happened on the menu and act accordingly.  Worst part is when a Tag changes for the menu for whatever reason.  It's a round of debugging I'd rather not have to do with my applications.

This would be nice     

In the picture above the event structure frame and the menu item are hard-linked.  No spelling mistake can lead to a bug here!

Instead of this         

In the picture above a spelling mistake on the case structure (or a change in TAG string) can lead to menu items not being acted upon.

Why can't we have a User Event for any given User Menu entry?  We could still use Tags and so on but have an additional field for a User Event (Data type always boolean?) which will trigger when the particular menu selection is made.  It would be up to the user to register for the event and wire it up to the event structure for it to become "live".  Default behaviour would therefore be the exact same as now.

Of course we only have statically-created menu items available like this for the event handler, but this already gives us easier handling of top-level UI menus.  Run-time created menus should also have events, but it's up to the user as to how to use these.  Either way, the original "one size fits all" menu event should also be fired (can be used for debugging amongst other things) so if it's not feacible to bind the event, the user can revert to the "old school" way of doing things.

The picture above shown all three user-events in a single event structure frame which doesn't really do the idea justice but the idea would be to have an event frame dedicated to a single event.

[JackDunaway]

For what it's worth, I'll link to the idea Link case structure to run-time menu and direct your attention to the first author in the comments. Had a change of heart, Shane?

Well, I'm with you in your campaign against fragile code, but the current method of handling menu selection events suits me well. One trick I like: rather than using ASCII labels for your RTM tags, dynamically build the menus using a flattened data structure (for instance, a cluster containing an enum and your data). This provides clean protocol for scalability and maintenance. Also, you can have the identical action for different sets of data (for instance, a "Recently Used" submenu under the File menu with the file path to several different files).

[Intaris]

Not a change of heart.  The other proposal isn't feasible as a string doesn't fit well with the idea.

The ability to have a stricter binding between menu entry and the code is the main advantage of my suggestion.  My idea also wouldn't stop you doing things the way you currently are.  It would give an additional (and for my 2c - cleaner - way of implementing menu functionality.  I much prefer to use strictly-typed user events instead of variants / strings for these operations because the non-strict middleman is eliminated.

[JackDunaway]

I agree, I like strict better than fragile. But the expense for a strict menu item requires you to give up run-time dynamic changing, unless you use two separate mechanisms, the current method of statically registering a weak datatype, or dynamically registering a strict datatype. There's not a win-win situation here, but I'd rather just have one event handling mechanism rather than two.

Continuing the conversation along a different thought.... if you were to dynamically unregister an event, how would the RTM itself respond? Is that item greyed out, does it disappear, or is it a "stubbed" out item that just does nothing? Could that action be configurable?

[Intaris]

Jack,

unregistering the event has no effect whatsoever on the RTM.  The RTM is removed using the LV Vi for that purpose.  I propose no change to this mechanism.  Unregistering for the event simply means that the event will not be fired if the menu if chosen (although the "one size fits all" event you use yourself would still be fired).

I don't see the disadvantage.  It's not a "one or the other" scenario.

"a strict menu item requires you to give up run-time dynamic changing" is not correct since nobody's suggesting a "strict menu item" at all.  I am simply trying to offer a different way to interact with dynamic menu items.  It would be nice if the use cases as illustrated above (menu statically being build in a VI) would have the extra benefit of making those events available on the event structure.  All other menu items have their events associated with them which the user can use or ignore at their whim.

[Darren]

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.