New event data element for value cluster of registered event sources

[mike-o-tronic]

I often run into the issue that I have one event case that I need to execute for multiple controls. Most of the times I simply read out the terminals and most of times I get the "NewVal" from the terminal. Some times however that's not the case. I'm currently having the issue that I use a property node of a control to trigger the event and every other time the terminal gives out the "OldVal".

I believe the proper way to solve this issue would be to go by the reference. I find this blows up the code more than it should do. Looking around in the community I've found two other ideas suggesting different solutions for this issue:

The first has multiple boolean controls triggering the same event. SectorEffector's solution was asking for a reference case structure, which might be a great idea, especially when the event is triggered by different data types. When I have multiple boolean triggering one event I almost always build an array from the terminals and convert the array to an integer, so that a case structure or other code can deal with the value. But again I'd have to deal with fiddling the new value from the triggering control and the other control values together.

The second mentions actually two ideas. The actual idea of rcpacini is to have an enum indicating which control triggered the event. This is a similar approach to what SectorEffector suggested. They're both aiming at using a case structure with a different cases for each event source. The alternative idea of rcpacini was to have event data elements for each control. The is more similar to my idea, but I would like to have the values of all registered event sources clustered together.

Here a side by side of the current solution and what I'd suggest:

New value by referenceNew value cluster

The order of the events would determine the order of the values in the cluster, so a way to arrange the events like a move up and move down button would be helpful:

Event source order up/down buttons

[wiebe@CARYA]

Both solutions are problematic, as those events can be dynamic.

You can get those events by dynamically registering for them, with an (at compile time) unknown list of controls.

If you want a cluster of values, why no put the values in a cluster? Than you'll get an event with all values in a cluster.

[mike-o-tronic]

If a cluster is a convenient structure in the front panel, I make it a cluster. Unfortunately that's not always the case.

And I don't see the problematic, but maybe I just don't know how to make it problematic...

As far as I know the data type of events, even dynamic events, must be defined at compile time and so must be the event case. The only thing that can change dynamically is the number of sources when the event is an array, but I'd simply expect this to be included as array in the OldValCl/NewValCl.

Dynamic event and their data type

The first event would add an array of booleans to the cluster the second an array of variables. The cluster would be defined with the event case.

If you have some example on your mind that wouldn't work, I'd be grateful to see it. Maybe it's something I'm simply not thinking of or best case it's some functionality of LabVIEW I didn't even know about... because learning never stops 🙂

[wiebe@CARYA]

>As far as I know the data type of events, even dynamic events, must be defined at compile time and so must be the event case.

You can re-register for Value Change events, and the types can change:

In a way you are right: the data type doesn't change. It's defined as a variant, because there are mixed types, and it stays variant. The Value Change event will return variants, so in lines with your proposal, an array of variants could be returned.

>The only thing that can change dynamically is the number of sources when the event is an array, but I'd simply expect this to be included as array in the OldValCl/NewValCl.

Not in your original proposal, where Value 1 and Value 2 are put in a cluster, not an array.

[mike-o-tronic]

Right and it has to be defined as mixed type event. If you try register a mixed type source for a boolean event, LabVIEW will tell you that won't work.

[wiebe@CARYA]

Yes.

[mike-o-tronic]

My original proposal was to cluster value change events as they're listed in the event specifiers and so was to include dynamic events as they're defined into the cluster. If the event case was defined with Value 1, Value 2 and the two dynamic events specifiers like this:

Event specifiers

The cluster would be defined by the data types of the events and the order of the event specifiers:

NewValCl with dynamic events

However, I wouldn't insist on the cluster. As I mostly define my events with sources of the same datatype and build an array from the data, as the example of the proposal shows, I would be totally happy with a OldValAr/NewValAr data element. It could look like this:

NewValAr data element for different event data types

There could also be an option in the context menu of NewVal to select either "event value" or "all values" or something like this.

[wiebe@CARYA]

What if the dynamically registered value is an array type? Would this result in variants or an array of clustered arrays?

[mike-o-tronic]

If you register an array value change as dynamic event you will get an event of the data type variant, so the result would be the same as the mixed array just with an array instead of a scalar value in the variant.

[wiebe@CARYA]

So I think that the mechanics are now technically defined.

Let's see if people like it.