UI-Triggered Event vs. Value (Signaling) Event?

[Nate@UT]

Is there any way from within the event structure (e.g. event data node) for me to discriminate whether that event handler was fired by a direct UI interaction (e.g. change of control value, typing in a string field, click of boolean button, etc.) versus a programmatic execution of the "Value (Signaling)" property node?  It would be very handy to be able to use logic in the event handler to act differently depending on the source.  I see a "Source" enum available in the event data node, but this seems to be "LabVIEW UI" no matter what, and never changes when I call this handler programmatically with write to a Val(Sgnl) node.  Thanks! 

[Kyle97330]

If you're using a Value (Signaling) node, you should be doing it with the express idea that the two events are equivalent, since that's the exact purpose of that node.

If you want to do something different on a programmatic change, just use a "user event", with the data of the user event being the new value, and then have the case that runs the user event write that value to the control as well as whatever else the event needs to do.

[Nate@UT]

Thanks @kyle97330... I'm aware of the user event approach, but it just gets messier with the extra create/destroy/register event blocks, a UE wire to track around, additional handler, etc.  It would be so much cleaner to have an additional enum in the "Source" data node which lets me decide in the handler if I want to do something different based on whether it was UI generated or property-node generated.  

[GerdW]

Hi Nate,

---

Nate@UT wrote:

It would be so much cleaner to have an additional enum in the "Source" data node which lets me decide in the handler if I want to do something different based on whether it was UI generated or property-node generated.  

---

Use a different event case for your "property-node" generated events (by using a different control).

Or use UserEvents instead! (That's what they are made for!)

[UliB]

---

@GerdW wrote:

---

---

Use a different event case for your "property-node" generated events (by using a different control).

---

You even do not need a different event case. You can handle two events from different controls in one event case. You then can use the control reference data node to distinguish between the controls, e.g. by reading the controls label.

---

Nate@UT wrote:

It would be so much cleaner to have an additional enum in the "Source" data node which lets me decide in the handler if I want to do something different based on whether it was UI generated or property-node generated.  

---

Time for LabVIEW idea exchange (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas)?

[rolfk]

And if you used a queued message handler architecture such as the JKI state machine or DQMH you would put the relevant code in its own state handler and trigger that from wherever you need in your VI. Yes the according event case is NOT implementing the operation but deferring it to a different explicit state that can be invoked from anywhere else too, if desired with extra parameters that can be used to determine source specific behavior.

Trying to determine after the fact who generated a specific event is a very common idea. But it always seemed to me like trying to put the cart before the horse. Instead start with an architecture that allows to annotate events with some parameters of some sort. Queued state machine designs are easy to do that with.