Programmatic Event Generation

[Ashley_Bryant]

A programmatic eevent can be generated using val(signal). The problem is that every time val(signal) is called it generates an event, (even when it is a non [false] event). Just like keyboard events that only occur when a key is pressed (and/or released), can val(signal) be modified to respond in the same way. In other words, if val(signal) is given the value "False", it should not generate an event, only generating an event when val(signal) is "True". This would make code writing so much easier and stop the possiblity of potential race conditions.

[crossrulz]

So this would be an additional input?  Sounds like it wouldn't be a property anymore, but an invoke method instead.  I'm not sure I like the idea of changing it to a method.  Simple case structure can take care of your problem.

[Dennis_Knutson]

It seems you are confusing a value change event with the value itself. Just calling the Value (Signaling) property is supposed to fire an event. The value of the control is separate. A change from false to true or a change from true to false are equally valid Boolean events.

[vitoi]

I agree with crossrulz. Just add a case structure (that is, an if) and therefore only call Val (signal) when the transition is to your liking.

Does this satisfy your requirement?

[Ashley_Bryant]

I am surprised by your comments, you don't seem to have grasped the issue. In the Event Structure, when and only when a key is pressed on the keyboard or when and only when a mouse button is pressed, is an event generated which can then be acted on by the Event Structure. However, when it comes to val(signal), irrespective of whether the Boolean is True or False it generates an event, it only has to be executed. It's the generation of an event whenever val(signal) is executed which is the issue. I also question the need to have a boolean attached to val(signal), what purpose does it serve, if not to signal whether the event is valid or not? Yes, the current functionality can be worked around and case statements added to convert the val(signal) behaviour into a behaviour which emulates keyboard and mouse event generation (can't seem to find a way to attach a code example to illustrate), but it makes code writing much more cumbersome. I like to keep things simple, it makes for much more cost effective code maintenance and code clarity. Programmatic event generation is really cumbersome in labVIEW and I don't think it needs to be that way.

[tst]

> I also question the need to have a boolean attached to val(signal), what purpose does it serve, if not to signal whether the event is valid or not?

The Val(sgnl) property generates a Value Change event on that control. The boolean is simply the data of the event and it's there because you're using the property with a boolean control. If you have it with a numeric control, the type would be numeric. That's why false is also a legitimate value.

If I understand your idea correctly, you basically want the property not to generate an event if the value hasn't actually changed. That's a legitimate request* (although I don't know if I would use it), but the question is how to implement it. I think the simplest option is to create a new property which will not trigger the event if the value hasn't changed. I would suggest you start a new idea for this and phrase it so that it's clear.

* In case someone is wondering why I'm not agreeing with the others that you can simply monitor the value change on the wire, the reason is that the actual value is associated with the control and can be changed from multiple points in the diagrams (yeah, yeah, race conditions, blah blah blah).

[Dennis_Knutson]

I fully grasped what you were asking for but you don't seem to understand the difference between a value change event and a key up/key down event. A value change event is used for Booleans, strings, and numerics. All of those have a value associated with the actual event. Discarding the value itself is not correct.

[KathrynB]

I'm confused as well, and if Val(signal) to False for a Boolean can be a valid state - this is often used as a property and can be called from elsewhere programatically. Sometimes systems work in a different way when you switch something OFF. For example a heating system is switched on by a Boolean and an event used to trigger the state machine that takes it to temperature and maintains it there. Switch the heating system off and then I'd want the same event structure to trigger the same state machine to cool the heating system. If I was programming something and didn't want my False to be acted on by the even structure then I'd just use Value instead as that won't trigger the event.

If you are talking about the value not actually changing then it is a different situation. The only time a Boolean is associated with a value for singalling or not is when the control/indicator in question is a Boolean, and hopefully the example above gives a good example for when that would be needed.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.