BUG: Nested cluster Value change events

[mcduff]

---

@Darren wrote:

---

@mcduff wrote:

---

---

On the Front Panel, a value change on the Tree cannot occur without a Mouse Down Event. 

---

While your VI is running, you can press the Tab key on your keyboard to set key focus on a tree control. You can then use the arrow keys on your keyboard to change the selected row (i.e. the value) of the tree control. No mouse interaction required.

---

This was meant as an example not an absolute. But you could always have the control skip tabbing, have a touch screen control with no keyboard, etc. This was only to show there is an event order, nothing else.

[mcduff]

---

wiebe@CARYA wrote:

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

---

It's a bug and unexpected behavior. 

[wiebe@CARYA]

---

@mcduff wrote:

---

wiebe@CARYA wrote:

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

---

It's a bug and unexpected behavior. 

---

I don't think we'll get to an agreement on this.

It doesn't matter anyway, little we can do about it.

[mcduff]

---

wiebe@CARYA wrote:

---

@mcduff wrote:

---

wiebe@CARYA wrote:

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

---

It's a bug and unexpected behavior. 

---

I don't think we'll get to an agreement on this.

It doesn't matter anyway, little we can do about it.

---

I do think it is bug, but not for the same reason as you. Your example of an element in a cluster seems like a bug to me, it should work like the nested cluster.  😉

[wiebe@CARYA]

---

@mcduff wrote:

---

wiebe@CARYA wrote:

---

@mcduff wrote:

---

wiebe@CARYA wrote:

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

---

It's a bug and unexpected behavior. 

---

I don't think we'll get to an agreement on this.

It doesn't matter anyway, little we can do about it.

---

I do think it is bug, but not for the same reason as you. Your example of an element in a cluster seems like a bug to me, it should work like the nested cluster.  😉

---

I do understand you feel that way, but I disagree.

[mcduff]

---

wiebe@CARYA wrote:

I do understand you feel that way, but I disagree.

---

This isn't politics or religion, it's fine to disagree.

This thread is going on too long and I and you seem tired of it. So let differences be differences, and there is a workaround. Have a flat cluster structure then your preferred execution occurs, put everything in a Matryoshka cluster and things will work in my execution order. 🙂 

[wiebe@CARYA]

---

@mcduff wrote:

---

wiebe@CARYA wrote:

I do understand you feel that way, but I disagree.

---

This isn't politics or religion, it's fine to disagree.

---

Yes, like I said: it's not up to us to change it anyways.

---

@mcduff wrote:

This thread is going on too long and I and you seem tired of it. So let differences be differences, and there is a workaround. Have a flat cluster structure then your preferred execution occurs, put everything in a Matryoshka cluster and things will work in my execution order. 🙂 

---

Or don't use clusters at all.

I find that clusters in UI's are very limited anyway, as controls and indicators can't be mixed. If there are a large number of controls\indicators, I go by reference...