(Optionally) List events the same way when selecting as when editing

[550nm]

I have a few VIs with many events in the event structure ( and I'm sure there are apps out there with orders of magnitude more events defined).

In an effort to get this list under control, why not employ the same structure used when we edit an event?

Or, at least, offer it as an option(?)

Below is what the event-list might look like if it used the same organizational structure as the IDE uses to present available events when editing them. Below that is what the option-dialog might look like, and, far below is what we have now (I used screenshots from LV20014 , but checked LV2017 to see if anything had changed by then. 😁).

[wiebe@CARYA]

You know you can add more than one event to an event structure case, right?

I'd have all those value change events in one event case, and in that case handle the appropriate action for the specific control. Often, the action is the same. For instance, get the control's label and store it's value.

Just saying, you might be able to avoid event structures like that...

[AristosQueue (NI)]

This is a neat idea. Wiebe raises a real concern: having multiple events handled by the same frame would pose a problem for this hierarchy view because things that are in different parts of the hierarchy would need to be listed as one item. It seems to me that we would have to special case those as "combo entries" at the top of the hierarchy tree. But the majority of events aren't combo events, so I can see this being quite valuable.

I like it, so, as a G programmer, I'll add my personal kudos to the idea.

Speaking for LV R&D, I do not know if we will get bandwidth to tackle this in LV 20xx. I'll flag it for our UX folks. But I will also flag this for the LV NXG team... they have a richer set of UI controls that would allow them to create this kind of drop list far easier.

Thanks for the suggestion.

[550nm]

Hi Wiebe,AQ,

Thanks (and apologies),  I'm merely suggesting that the tree structure already used for organizing available events, could serve to organize the user's events. This is just an example cut and pasted together in MS Paint and the apparent conflict in the first image is accidental.🙄

I'm aware that one event case can handle multiple events (there are several examples shown in the last image). In that case, clicking on any of those "leaves" in the event "tree" would take you to the same event-handling case. I imagine two different events from the same source - like mouse-move, and mouse-enter - would require separate leaves on the tree.

[AristosQueue (NI)]

Ah, so you would have a multiple-event frame be listed as two separate entries in the tree. That's an option. If UX picks this up, they'd do some usability tests to evaluate that.

[550nm]

I see the tree as a place where each of the user's-events appear once. Since there can be only one event-case/frame for an event, selecting an event, selects a frame - the frame where the event is handled. Multiple events can "point" to the same frame.

The current frame-listing is potentially unwieldy. This isn't going to help the app that's handling 10 events. It may help the app that's got hundreds or thousands of controls spread over multiple tab-controls and bundled in clusters. When "Joe-Tech" want's to find the frame handling the event for "actuator 43, on pump-station 9, in building 6", or the "Gate setting on the optical spectrometer page of the devices table on a diagnostic screen of a scientific app..

[RavensFan]

---

@AristosQueue wrote:

Ah, so you would have a multiple-event frame be listed as two separate entries in the tree. That's an option. If UX picks this up, they'd do some usability tests to evaluate that.

---

I would make sure that any entry in the tree as some symbol next to it to indicate that it is one of a combo event, that entries will lead you to the same place.  I'll use an asterisk in the example. Perhaps still have the case # be a part of the string.  So a list sorted by hierarchy might look like:

[0]  Lone event A

[1] Lone event B

[2] Lone event C

[3*] Combo event D

[7] Lone event E

[8] Lone event F

[3*] Combo event G

[15*] Combo event H

[22] Lone event  I

[33] Lone event J

[19] Lone event K

[15*] Combo event L

.....

Now you'll know that events D, G, H, and L all have other events attached to the same case frame, and with the actual frame number, you could scan the list quickly to find the matching one (3 for D and G,  15 for H and L)

[RavensFan]

Ah, so you would have a multiple-event frame be listed as two separate entries in the tree. That's an option. If UX picks this up, they'd do some usability tests to evaluate that.