Event Case Firing/Executing on an Indicator Value Change

[Rich_1]

In order to get an event case to fire on an indicator value change some complexity has to be created in the code, resulting in it being convoluted. It would be very useful if event structure cases could be revised to detect and fire on value changes of indicators as well as local variables.

[RavensFan]

I don't understand what you are considering complex code.

Indicators have a Value (Signalling) property node just like controls.  You just use that property node whenever you want to fire an event structure.

[Rich_1]

Agreed, using the the Value(sgnl) PN will fire a value change event case, however, everytime the Value (sgnl) PN is written to the case fires even if there was no value change. To prevent this the write to the Value(sgnl) node has to be within a case structure such that it only occurs when the variable changes value. This is what I meant by adding code complexity. This extra layer of code could be avoided if the event case would trigger on the indicator value change directly.

[RavensFan]

Duplicate of

Programmatic Event Generation

Modify behavior of value change event for LabVIEW controls

[AristosQueue (NI)]

RavensFan: No, this is not a duplicate of those other two ideas.

Rich_1: Your idea leads to lots of significantly more complex code. We very specifically do not allow events to be raised by the programmatic modification of the values of controls/indicators. This was emphatically rejected by R&D during the development of events and has been confirmed multiple times since then. The reason is that modification of the events through programmatic writes to indicators has a high probability of creating the echo chamber code that we see in other UI systems that raise events for everything. LabVIEW avoids that issue. If you intend for an update of a UI element to be an event that can be heard by other systems, use Value(Signaling) explicitly instead of the FP terminal. Note, however, that use of Value(Signaling) as a major way to broadcast changes to the rest of your code couples your UI with your code in ways that are generally undesirable, so generally we recommend restricting Value(Signaling) to the UI raising events for itself, not for other components. Create custom user events for signaling to or from your back end code (any application that is sufficiently large to have a well defined division between front and back will benefit from that rule, generally).

This rule that "only Value(Signaling) raises events" and no other ways of updating the UI does is a critical part of our design for stoping the echo chamber and avoiding endless cascades of Value Changed events when trying to keep two controls in sync. Yes, the echo chamber can be stopped by sufficient code within the event handlers, but that's generally a larger amount of code.

If you are looking for a mechanism for *intercepting* a front panel that was not written to generate such events, LabVIEW does not have it. Having some other piece of code "attach itself" to an existing panel is a commonly desired technique that is regarded as either the greatest thing since sliced bread or the most unmaintainable hack ever invented, depending (in my observation) upon whether you have more commonly created UI code or inherited someone else's UI code. Regardless of whether or not it is a good thing or a bad thing, LabVIEW does not have such a mechanism, for reasons mentioned above.

Having said all that, we have been known to revisit fundamental decisions of features. If you have examples of code that is substantially more complex under the current paradigm, please post images here. I suspect however, that using User Events to do your signaling outside your UI and within your UI simply replacing your local variables with calls to Value(Signaling) will suffice to fix your issues. I haven't seen your code, so this is a bet based solely on observation of the code of other users.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.