Events triggered in parent from change to XControl data

[Joel]

I built a test XControl whose Data can be changed by either:

  1) Changing the value of a control on the XControl facade, which in turn updates the Data of the XControl and sets Data Change? in the XControl Action cluster to true.

  2) Writing to a property of the XControl.  This changes its state, and the state change event case updates the facade control, updates the Data of the XControl, and sets Data Change? in the Xcontrol Action cluster to true.

I then wrote a Test XControl.vi to probe the behavior of this XControl.  As expected:

 a) The facade control updates with either method.

 b) The XControl data read in a polling loop also updates correctly.

However, only method 1 triggers an event in Test XControl.vi  This confuses me because I thought that the triggering of an event would be mediated by the Action cluster, which is handled the same way by both methods.  

My code is attached.

Even more confusing is that this is a simplified XControl.  In my original XControl, an event in a testing program would not be triggered by a property call initially.  However, after the facade control was manually changed once, subsequent property changes would trigger the event.

Suggestions?

I am running LabVIEW version 20.0f1 (32 bit) on W10.

[paul_cardinale]

The XControl in the .zip file doesn't have any properties.  Also, the name of the XControl ("XControl.xctl") doesn't match the name of the XControl that "Test Xcontrol.vi" expects ("Test XControl.xctl").

[Joel]

Hi Paul,

  I deeply apologize for wasting your time.  I extracted these routines from a project, and didn't do it correctly.

   I've attached a corrected version, which I've tested from the zip.  It still exhibits the odd behavior.

Joel

[paul_cardinale · Accepted solution]

The "XControl": Value Change event (in your upper loop) will only be triggered by 2 things:

1. User interaction with the XControl on the front panel.
2. Writing to the "Value Signaling" property of the XControl,

[Joel]

Thanks Paul,

   So, to conclude, there is no way to programmatically cause an event on the XControl data  in the parent from within the XControl?  I.e., there is no equivalent of "value signaling" that is executable within the XControl?

Joel

[BowenM]

Joel,

If I'm reading your question right, Paul already answered your question. Instead of setting Value with property node, set Value (Signaling). It should give you your expected behavior.

Side note: I know this was just a demo, but you really don't ever want 2x event structures in a single VI...

[paul_cardinale]

---

@Joel wrote:

Thanks Paul,

   So, to conclude, there is no way to programmatically cause an event on the XControl data  in the parent from within the XControl?  I.e., there is no equivalent of "value signaling" that is executable within the XControl?

Joel

---

The components of the XControl receive the refnum to the instance of the XControl.  Try writing to its Value Signaling property.

[BowenM · Accepted solution]

---

@paul_cardinale wrote:

---

---

The components of the XControl receive the refnum to the instance of the XControl.  Try writing to its Value Signaling property.

---

Oh, wait... you're wanting to send value signaling to parent from within the XControl?

I would be extremely careful doing stuff like this.  XControls are not the most robust construct, and it is easy to program yourself into a corner where you can't do what you thought you could, or where the XControl itself ends up in a permanently locked state because you're using a reference to itself inside the control directly.

I only bring this up because I've made this mistake more than once. In fact, XControls are easy enough to screw up when you try to do something fancy that I've almost stopped using them altogether. Instead, I'll usually write a class that gets a control ref fed in on initialize. When I do use XControls, I try to keep the behavior very simple and strictly cosmetic to the indicator (ie changing colors of indicator when a numeric value is out of limits).

If you still want to use XControls for this, I think a better method would be to feed a user event into the XControl and save it as state information. Then call the user event when you want to send an event back up. It'll make the event more dynamic so you can send additional data back up if needed.  I also suspect that while the Value Change (signaling) event would work, that it isn't "officially" supported as part of XControls. Like I said, I've screwed myself more than once trying to mess with internal references.

Best of luck.

[Joel]

Thanks all, for clarifying this for me.

Though using "Value Signaling" does generally work, it doesn't work in my case.   The property I am setting is not the XControl Data itself, but some State data from which the Data is computed.  "Value Signaling" sets the data directly.  Thus, I would need to set some apparently non-existent " "Value Signaling" " inside the XControl itself.

But I take Bowen's point very seriously.  Despite the elementary nature of my question here, I've had a lot of experience with XControls starting when they first came into LabVIEW, and I agree that they are very difficult to debug and lead to mysterious LabVIEW crashes etc.  Over the years I've developed a prototype that I use almost exclusively which is fairly stable, this exchange was about doing something that I had never tried before.  And clearly I don't entirely understand what the Action cluster does as I thought it would trigger a parent Event.

[tst]

---

@Joel wrote:

Thanks Paul,

   So, to conclude, there is no way to programmatically cause an event on the XControl data  in the parent from within the XControl? 

---

Well, which event would you register for in the calling VI other than the value change event? There's only a limited list of built-in events. You might be able to use one of them (I haven't checked), but that would be a kludge.

You could use a user event, but you would then need to register for it in the caller and pass the reference of that event to the XControl (using a property or invoke node), so it would know how to generate it.

Never mind, I think I misunderstood the later comments.