Event Selector for Multiple/Different Data Types in Event Structures

[rcpacini]

I haven't seen any other posts on this but i could be mistaken. It would be helpful to include an enum of which event fired for "Value Change" or other events, especially for different data types. Currently you have to use the CtlRef to get the label or class ID to identify which datatype/control fired and then use a Variant to Data to convert the datatype correctly. Two ideas came to mind to simplify this operation. First, add an Event enum which consists of all the objects for that particular event. This enum could then be wired to a number of finite cases eliminating invalid datatype problems of using the label names which could change during development. Second, since labview always keeps track of old values for each control in an event structure, it could always give the ability to choose any old and/or new values for each control (shown below). Let me know what you think?

[Intaris]

If you need this functionality you really should have two seperate event frames.

I don't see the benefit of implementing this in LabVIEW.

[Mads]

Intaris - if you need to perform the same process in each of those frames you currently only have the option to make a sub-VI of that process and use it for each event - or create a user event and fire it for every event case - if you want to avoid duplicating the whole code for each case....Rcpacinis idea would make things easier and I'm sure it is feasible, so why not just make it as easy as possible?

[Intaris]

But if you perform "the same process" then why is it neccessary to have the case structure in the first place?

An event on a control delivers a refnum to the control already (CtlRef in the top left pciture), surely it would be possible to use this to determine which control was fired (as stated in the original post)?  I still don't see the need for an adidtional functionality of the event structure (well, not this one).

The suggested "solution" is not a simplification at all.

[rcpacini]

Like i posted already, you have the ability to figure out which control was fired from the CtlRef by a method of your choosing but due to inconsistencies in changing properties of a control at run time, the way you identify the control can change, that's where an enum (which cannot change at run time) would be useful. The idea of the enum is to allow the developer to distinguish which control event is executing and the case structure allows for uniquely data typed code but the case structure does NOT have to be used. To Mads' point, combining multiple events for the same process eliminates code duplication and discrepancies associated with duplication.

[Intaris]

But the ability to distinguish is already given via the control reference.  The name of a control CANNOT change at run-time, neither can its class.

Why create a duplicate method?

[AristosQueue (NI)]

I agree with Intaris. He mentions that the name and class of a control does not change. Even easier: the refnum of the control doesn't change either. Just have a constant control refnum inside the frame and use an equals primitive to see whether its the same as the one from the event.

[JackDunaway]

In part due to a conversation I had with LabBEAN, I'm now aware your bottom diagram on the right exhibits low cohesion: the event data on the the left hand side of the event structure creates an interface to data elements that are mutually exclusive. If the Boolean event fired, the Numeric prefixed data is null, and vice-versa. The "function" (the case structure) would have two mutually exclusive cases, one which used the Numeric inputs, and the other used the Boolean inputs. Mutually exclusive DATA in addition to mutually exclusive FUNCTIONS would be better broken into separate functional blocks (e.g., two separate event cases). As a consequence, you'll likely loosen "coupling" between the functional blocks, which is a good thing.

The top diagram on the right is also not legitimate because labels can be BLANK, and they can also be DUPLICATE in a diagram (this is not your fault, I think this is a design SNAFU of LabVIEW that I've never heard a good reasoning for).

Basically, you're relegated to the current method of comparing references directly using the Equal? operator, as AQ suggests.

[Mads]

Intaris - you wrote: "But if you perform "the same process" then why is it neccessary to have the case structure in the first place?"

I think you misunderstood me - disregard the Case structure in the example (that is not really relevant for the idea itself, so I did not even notice it) - I was talking about having the same process happen for different *Event* cases. Today you can link one event case to multiple event sources - however when you do so you have to add code to handle the fact that you will not have as easy access to which control it was that fired the event and, if the data types vary, you also get the value as a variant. That is the downside I am under the impression that this idea is addressing.

Sure, as I mentioned myself too, there are plenty of ways to treat this...but just because there are solutions available already does not make this idea bad. The key here is that if it was implemented I'm quite sure you would end up using it as well, instead of the current ways of solving it.

[Intaris]

"will not have as easy access to which control it was that fired the event"

But I think you DO have an easy way already. Plus if I imagine the number of output terminals you would need in your event frame if you had mapped 20 controls to a single frame then it nearly makes me cry.  What's supposed to be readable or "good" about that?  Sure an example for two controls might work out but scaleability is miserable to more then only a handful of controls.  And this handful of controls can be dealt with easily in other ways.

"there are plenty of ways to treat this...but just because there are solutions available already does not make this idea bad."

Well in my opinion it does not make id bad but unneccesary if it doesn't bring anything valuable enough to the table.

"The key here is that if it was implemented I'm quite sure you would end up using it as well"

I'm pretty sure I wouldn't.  I try vigorously to avoid the situation you describe being the root cause of the problem.  I feel it significantly decreases the readability of the code and the little bit of code duplication (That's why we have sub-VIs folks) is nothing in comparison (IMHO).