value signaling with user-event.

[labmaster]

In the event structure for variable1, value-signaling is useful for quickly checking results during programming work elsewhere.

However, I know there are situations where value-signaling does not work. (Exactly in which situations?)

That’s why I often see recommendations to use user-events. In other words, it seems possible to share the variable1 event and the user-event structure.

But if the value of variable1 is needed, how should the update of variable1 be handled in the shared loop?

My current thought is that I should manually update variable1 using a property node before sending the user-event.

Is there a more reliable method for robust event handling?

labmaster.

[altenbach]

Can you attach a simple example so we can be more sure what you are actually talking about?

What is a "shared loop"? Where is "elsewhere"?

I assume your "variable1" is actually a control, so why not place the terminal inside the event case?

[labmaster]

As per your request, I have attached the example.

My question is whether it’s worth going through the complexity of combining value property and user-event just to handle cases where value-signaling is ignored.

I’m also wondering if it’s really necessary to use value property or local variable at all.

labmaster.

[GerdW]

Hi labmaster,

---

@labmaster wrote:

I’m also wondering if it’s really necessary to use value property or local variable at all.

---

This is only because you created one (1) event case that handles two events:

• value change of the control
• user event for to circumvent the value change event of the very same control

If you would create a single event case handling JUST this user event then the event data node would also provide a terminal for the event data! Then you don't need any additional locals/globals/property nodes to send the value into the event case...

---

@labmaster wrote:

My question is whether it’s worth going through the complexity of combining value property and user-event just to handle cases where value-signaling is ignored.

---

What are your cases of "value signalling is ignored"?

How (and why) do you ignore such an event?

Why do you create this "additional complexity" by combining event cases and "ignoring value signalling"?

[labmaster]

I know full well that it was a silly question. Creating a loop for value signaling would work, but reducing the cases in the event structure makes it easier to understand later on.

Out of a long-standing habit—like thinking that local variables shouldn't be used—I once struggled because I used value signaling and couldn't receive events. I don't remember the details of that situation very clearly.

In fact, the event common logic contains several pieces of code, and trying to use them by duplicating felt like I was committing some kind of sin.

This as well—since programming isn't my day job, I end up wasting even more time agonizing over these foolish situations.

labmaster.

[Yamaeda]

---

@labmaster wrote:

However, I know there are situations where value-signaling does not work. (Exactly in which situations?)

---

Writing to a Indicator, Value property node or Local variable doesn't trigger a value change event. You must use a Value (signalling) property node. 

That however assumes you have and use a front panel and it requires the slow UI thread. For most systems it's better to use a User event which handles such things in the background. If you're making a UI then value(signalling) is ok. 🙂

[altenbach]

---

@Yamaeda wrote:
That however assumes you have and use a front panel and it requires the slow UI thread. For most systems it's better to use a User event which handles such things in the background. If you're making a UI then value(signalling) is ok. 🙂

---

Without an UI, the [input:value change] event is also a bit strange.

One code choice that can lead to endless confusion is your decision to overload the label "Input" for both a control and a user event, even though there is no relation between the two.

In any case, if you just want to update the value of the "input" before the other event fires, a local variable seems like a better choice than a value property node, assuming that the control resides in the same VI.

Both your boolean controls should probably be latch action.