BUG: Nested cluster Value change events

[mcduff]

---

@JÞB wrote:

---

@mcduff wrote:

---

@Yamaeda wrote:

---

Effect - Value of child changed through Parent property, only fires single event.

---

okay, now I am starting see the issue

---

Imagine how filled up the Event Queue would get if you signaled VC events for every value in "Clustersaurus Rex!"  And that is the alternative, "Carpet bomb" every data value, even if there are hundreds of them!  So, signaling only signals a VC Event on "ThisObject." 

---

But the converse does not appear to be true. A VC event in a child cluster also fires another event.

[wiebe@CARYA]

---

@JÞB wrote:

---

@mcduff wrote:

---

@Yamaeda wrote:

---

Effect - Value of child changed through Parent property, only fires single event.

---

okay, now I am starting see the issue

---

....Which is not an issue!  The property node only signals a VC Event on the object it refers to and not every component of every data element inside the containing object.  

Imagine how filled up the Event Queue would get if you signaled VC events for every value in "Clustersaurus Rex!"  And that is the alternative, "Carpet bomb" every data value, even if there are hundreds of them!  So, signaling only signals a VC Event on "ThisObject." 

---

But if you don't want that as a programmer, don't register for the events! Simply register for the parent VC, and you won't get a carpet bomb.

If you do register for the event, I'd assume you want to get the events.

[mcduff]

---

wiebe@CARYA wrote:

---

@JÞB wrote:

---

@mcduff wrote:

---

@Yamaeda wrote:

---

Effect - Value of child changed through Parent property, only fires single event.

---

okay, now I am starting see the issue

---

....Which is not an issue!  The property node only signals a VC Event on the object it refers to and not every component of every data element inside the containing object.  

Imagine how filled up the Event Queue would get if you signaled VC events for every value in "Clustersaurus Rex!"  And that is the alternative, "Carpet bomb" every data value, even if there are hundreds of them!  So, signaling only signals a VC Event on "ThisObject." 

---

But if you don't want that as a programmer, don't register for the events! Simply register for the parent VC, and you won't get a carpet bomb.

If you do register for the event, I'd assume you want to get the events.

---

I am guessing it has to do with the Event Order. For example, a Mouse Down Event occurs before a Value Change Event in a Tree (if using the mouse). Similarly here, a change in the nested Child occurs before the Main Cluster.  When you change the Main Cluster using a Value(Signaling) node even if you make a change in the Child Cluster, the Event queue assumes the event that preceded it already occurred, that is, a Value(Signaling) change can only trigger proceeding Events, not preceding Events.

[JÞB]

---

wiebe@CARYA wrote:

---

@JÞB wrote:

---

@mcduff wrote:

---

@Yamaeda wrote:

---

Effect - Value of child changed through Parent property, only fires single event.

---

okay, now I am starting see the issue

---

....Which is not an issue!  The property node only signals a VC Event on the object it refers to and not every component of every data element inside the containing object.  

Imagine how filled up the Event Queue would get if you signaled VC events for every value in "Clustersaurus Rex!"  And that is the alternative, "Carpet bomb" every data value, even if there are hundreds of them!  So, signaling only signals a VC Event on "ThisObject." 

---

But if you don't want that as a programmer, don't register for the events! Simply register for the parent VC, and you won't get a carpet bomb.

If you do register for the event, I'd assume you want to get the events.

---

That breaks with a simple example:

GIVEN: a control of cluster1 of clusterA, clusterB and VC Events for cluster1, clusterA.Element0 and clusterB.Element0.  Do you fire the ClusterB.Element0 Event each time you change the value of ClusterA.Element0 by signaling a value to Cluster1?  Nope, you grab a ref to ClusterB AFTER you realize that your FP data display needs to be rethought. 

Did you REALLY pass in "Clustersaurus Rex " to a User Interface?

[mcduff]

The more I think about this, I think it is due to Event execution order, if it didn't follow an order you would end up in an infinite loop.

For example

Value(Signaling) Main changes Nested Cluster which in turn triggers a Nested Cluster Event which in turn triggers another Main Value Change Event which triggers another nested Cluster Event, etc. If it runs as you want you would be caught in an infinite loop. Why would it stop?

I don't think this is a bug.

[wiebe@CARYA]

---

@JÞB wrote:

---

wiebe@CARYA wrote:

---

@JÞB wrote:

---

@mcduff wrote:

---

@Yamaeda wrote:

---

Effect - Value of child changed through Parent property, only fires single event.

---

okay, now I am starting see the issue

---

....Which is not an issue!  The property node only signals a VC Event on the object it refers to and not every component of every data element inside the containing object.  

Imagine how filled up the Event Queue would get if you signaled VC events for every value in "Clustersaurus Rex!"  And that is the alternative, "Carpet bomb" every data value, even if there are hundreds of them!  So, signaling only signals a VC Event on "ThisObject." 

---

But if you don't want that as a programmer, don't register for the events! Simply register for the parent VC, and you won't get a carpet bomb.

If you do register for the event, I'd assume you want to get the events.

---

That breaks with a simple example:

GIVEN: a control of cluster1 of clusterA, clusterB and VC Events for cluster1, clusterA.Element0 and clusterB.Element0.  Do you fire the ClusterB.Element0 Event each time you change the value of ClusterA.Element0 by signaling a value to Cluster1?  Nope, you grab a ref to ClusterB AFTER you realize that your FP data display needs to be rethought. 

Did you REALLY pass in "Clustersaurus Rex " to a User Interface?

---

If you want to, yes.

If you don't, no.

It's an open playground, do what you want.

But if the rules are inconsistent, we're in trouble...

If the nested value isn't a cluster, you do get a VC event. So either that's a bug, or not getting a VC event on a nested cluster is.

I don't use clusters much, nested clusters even less, but AFAIC: you register for a VC, you change the value with signaling, you should get a VC event...

[wiebe@CARYA]

---

@mcduff wrote:

The more I think about this, I think it is due to Event execution order, if it didn't follow an order you would end up in an infinite loop.

---

What's the difference between a nested cluster and any other nested control? 

---

@mcduff wrote:

For example

Value(Signaling) Main changes Nested Cluster which in turn triggers a Nested Cluster Event which in turn triggers another Main Value Change Event which triggers another nested Cluster Event, etc. If it runs as you want you would be caught in an infinite loop. Why would it stop?

---

Events don't fire events.

The Value (Signaling) triggers the events, from deepest nested value to top level control If events are registered, they are triggered.

There's no loop there.

[Yamaeda]

---

@mcduff wrote:

The more I think about this, I think it is due to Event execution order, if it didn't follow an order you would end up in an infinite loop.

For example

Value(Signaling) Main changes Nested Cluster which in turn triggers a Nested Cluster Event which in turn triggers another Main Value Change Event which triggers another nested Cluster Event, etc. If it runs as you want you would be caught in an infinite loop. Why would it stop?

I don't think this is a bug.

---

I guess that's the reason, yes. It should however be noted and explained somewhere. 

[mcduff]

---

wiebe@CARYA wrote:

The Value (Signaling) triggers the events, from deepest nested value to top level control If events are registered, they are triggered.

There's no loop there.

---

Data flow would be violated if it worked that way. I set a trigger for a Value (Signaling) for the top level control, in this trigger I am actually changing a nested control that I am also registered for. If the event started from the deepest nested registered value that would violate dataflow, because I programmed aValue (Signaling) for the top level first. If the trigger went from top to bottom, then you would have a problem also, because once you hit bottom, that would start triggering everything above it again.

---

wiebe@CARYA wrote:

---

---

What's the difference between a nested cluster and any other nested control? 

---

There is no difference. There is a execution order for nested controls, you don't necessarily need a nested cluster. In the example provide in this discussion register Code 2 in the nested cluster for a value change event. If you change that value manually, then the event order is Code 2 change, Nested Cluster Change, Top Cluster change. Events have an order and precedence. 

[mcduff]

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)?