LabVIEW
BUG: Nested cluster Value change events
@mcduff wrote:
Here is one more, somewhat crazy, example that may/may not convince you, this is not a bug and expected behavior.
One the front panel I have a Tree Control. The only way to interact with the control is with the mouse. I am registered for the following events: Mouse Down and Value Change. If I change the value on the front panel with the mouse the following events occur: mouse down, then value change. That is always the order of events.
Now in my block diagram I set the Value(Signaling) property node. What events should trigger? Should it be only a Value Change Event (no bug) or a Value Change and Mouse Down Event (bug)?
Why on earth would you expect a Value (Signaling) to trigger a mouse down event?
This has nothing to do with nested controls nor cyclic event nor events triggering events.
Value (signaling) triggers a Value change event, it's not a simulation of a user clicking to change the value. That is the reason a VS triggers a VC and not a Mouse Down event.
Again, no event triggers another event. The user clicks, that triggers a mouse down event. The click triggers a value change, that triggers a value change event.
Search LabVIEW like a graph! 
Here's a strong indication that events are not generated by events (but instead by the Value (Signaling).
The TO is the only event in the event structure: what you see is all there is.
Boolean 1 is a control in each and every way exactly the same as Cluster 2 is a control...
So why does the Value (Signaling) put a Cluster and a Boolean 1 VC event on the event queue, but not a VC event for the Cluster 2?
Well, at least it's not expected, and even if you would expect it, it's debatable to a degree that there should be documentation added to the help.
wiebe@CARYA wrote:
Here's a strong indication that events are not generated by events (but instead by the Value (Signaling).
The TO is the only event in the event structure: what you see is all there is.
Boolean 1 is a control in each and every way exactly the same as Cluster 2 is a control...
So why does the Value (Signaling) put a Cluster and a Boolean 1 VC event on the event queue, but not a VC event for the Cluster 2?
SpoilerBecause it's a bug...
Well, at least it's not expected, and even if you would expect it, it's debatable to a degree that there should be documentation added to the help.
Look at the event log in Message 5, two events occur when the subelement is changed.
Maybe you should have NI chime in, I still do not think this is a bug and if worked the way you want it to work then there would be issues.
@mcduff wrote:
You are expecting the the Value(Signaling) to act just like Front Panel Event, so why not? (I do not expect this behavior that is why I do not think this is a bug.) You are expecting the Value(Signaling) Event in Main Cluster to trigger any events subelements in that cluster may be registered for.
I absolutely DO NOT expect a VS to act like a Front Panel Event.
@mcduff wrote:Why do you expect events for actions that preceded the Value(Signaling) Event?
I don't.
I expect value change events when the value changes (or it can actually stay the same if VS is used).
A value signaling should trigger a value change event.
All your logic doesn't explain why this works for an element in a cluster (expected), but not for a cluster in a cluster (expected).
@mcduff wrote:
wiebe@CARYA wrote:Again, no event triggers another event. The user clicks, that triggers a mouse down event. The click triggers a value change, that triggers a value change event.
Look at the example provided in the beginning of the post. I change the subelement of a cluster then another event occurs, value change of the main element. It is actually the same event, but two event cases are executed.
It's not the same event.
2 events are enqueued, because two events where registered.
I flush the events. If it was 1 event, the other would be empty.
