Allow unwired signaling properties to fire events

[altenbach]

Writing to a signaling property of a control fires an associated value change event, even if the actual value does not change.

That's a good feature!

I often have a situation where I want to fire an event without actually changing the value (Yes, I have good reasons!), so I end up reading a local and wiring to a signaling property of same. This seem silly!

I would prefer if we were allowed to leave the signaling property unwired, in which case it would fire associated events using the existing value of the object. Of course this should now work equally well for value change events of latched booleans where actual writing to locals and value properties are not allowed.

Leaving it unwired will simply fire the event, but not touch the value.

If this seems too convoluted, how about making a new method or property that does not have an input and is e.g. labeled "fire value change event".

[crelf]

I'd prefer the option of firing a general event - not a value-change (because, well, the value didn't change), but something else (kind of like a nudge).

[K1200LT_rider]

I like it... I vote for a "nudge" event.

- Brad

[Matthew_Kelton]

I would rather not see it get limited.  Any event that shows up in the event structure for a control should be able to be fired if desired.  I like the invoke node idea best.

[AristosQueue (NI)]

[Note: The following is not directly my area of expertise. I am passing along design decisions and feedback I've heard about event handling over the years. I am describing the reasons for the event structure's current behavior to the best of my understanding, but as this is outside of my usual domain, I'm flagging this as having an unusually high chance of being inaccurate.]

> Any event that shows up in the event structure for a control should be able to be fired if desired.

This is explicitly opposed by the design spec for the Event Structure. We've seen too many apps in other languages where event spawning triggers an infinite tail chase: the UI has two controls that are both supposed to update in unison. The user clicks on a control, generating a mouse clicked event. The event handling code simulates a mouse clicked event on another control. The handler for that other control's event generates a mouse clicked for the first control, and infinite loop ensues.

To avoid this, the design spec called for all events to be EITHER UI spawned (something you could not trigger programmatically) or user-defined (somethng that LV would never spawn itself). 

The first few versions of LV with the Event Structure did not have the "Value (Signaling)" property for exactly this reason. Having VSig opens the door to these infinite event spawns. We finally decided that the utility of this one particular event outweighed the risk of the infinite loop, so VSig was added. It was added very reluctantly, and over the protests of some architects of the event system.

The only other events that can spawn both from LV and from user code are PanelClose and AppExit. Originally, AppExit did not spawn if LV was closed from the AppExit primitive because that wasn't initiated from the user interface, and PanelClose didn't happen if you closed the VI using the FP.Close method. These were added because there was a need for a place to put clean up code for an application that would be guaranteed to run. [Tangent: PanelClose isn't actually guaranteed to run to completion if it occurs as part of AppExit. The only place for code that is guaranteed to run when you shut down is AppExit.]

The intended design pattern is that you have one place that you handle the LV-spawned events and from that you generate one user-defined event that all  of your controls actually respond to. So in the mouse-click example I have above, the correct mechanism would be:

1. Event loop catches mouse click on either of the two controls.

2. Handler generates a "MouseClickedOnOneOrTheOtherOfTheTwoControls" user-defined event.

3a. Two separate handlers both listening for the user-defined event each updates its respective contol. 

or

3b. A single handler for the user-defined event updates both controls. 

In either 3a or 3b, no futher events are spawned by the handlers. 

This syntax is arguably bulky, but it makes the feature a lot less error prone, which opens up its usability to a greater range of users. An easier syntax would allow power users to write their interfaces faster, but it creates problems for the less experienced programmers. Since the goal of LV is to open up programming to the greatest range of users who may or may not have any other programming experience/training, the preference is for the harder-to-mess-up systems.

That, to the best of my knowledge, is the philosophy that guides the entire event model of LabVIEW and the reason why there is no general mechanism for firing the UI events.

[Matthew_Kelton]

Aristos:

I understand your argument and I have gotten around the issue exactly how you explained, by creating user events (or if I have an queued action engine, having the event add an item to the queue), then having the other code call the custom event or state.

I guess what bothered me more about your repsonse is the idea of removing functionality so that programmers don't make mistakes.  All of us have run into an infinite loop scenario and LabVIEW gives us the tools to debug it.  While your solution works, it doesn't prevent the infinite event loop scenario.  To remove functionality for "dumb" programmers seems to be a slippery slope.

[JackDunaway]

Just a snapshot from an initialization sequence I was working on today:

A "Nudge" or "Auto-Signal" would have been nice here. (By the way, "Playing" is not a latched Boolean, in case you're about to scold me for not having the terminal in the Value Change event! 🙂 )

[ThiCop]

I vote for the second option.

[altenbach]

Here is a remotely related scenario:

I recently had the need to fire a "cursor move" event. Typically the user moves a cursor, firing an event to do a lot of recalculations based on the new cursor position. Under certain rare conditions, I need to move the cursor programmatically, but trigger exactly the same recalculations. What if we had "Cursor.PosX(Sgnl)" or "Cursor.Index(Sgnl)" etc. events? (Maybe this could turn into a seperate idea if there is interest.)

[wiebe@CARYA]

A potential problem with relaying events to user events, is limiting the number of events.

The UI event can limited the number of events. The 'manual' trigger might be able to limit the number of events.

However, if both generate user events, we can't easily limit the number of user events. Flushing events doesn't seem to be quite as efficient, although it helps.

Of course if we could limit the number of user events, that problem would disappear.