LabVIEW
Latched Booleans and Vallue Signaling
@dadreamer wrote:
@rolfk wrote:
A typical case of:
Patient: "Doctor it hurts when I press on this spot on my body."
Doctor: "Then don't press on that spot!"
Ha! We have a similar joke in my country.
But frankly speaking, I don't see serious reasons, why setting Value (Sgnl) for a latched boolean should be prohibited. It doesn't violate anything in LabVIEW paradigm as X. already stated in that Idea topic. It was just causing a race condition and/or Event undefined behaviour inside LabVIEW internals according to AQ and probably nobody ever cared to figure out why and make a proper fix to it (not a stub condition with an error message as implemented).
Or maybe fixing it broke other stuff. But really, if you wanted to use a Value (Sgnl) property, just make the mechanical action "Switch when released" and then manually set it back to false in the event case that handles it.
@dadreamer wrote:
@billko wrote:
Or maybe fixing it broke other stuff. But really, if you wanted to use a Value (Sgnl) property, just make the mechanical action "Switch when released" and then manually set it back to false in the event case that handles it.
Sadly I don't need this, because I'm already using ways like that proposed by Basjong53 above. Anyway, good advice for LV beginners like the OP was. Only wish, he would know about that in 2014. I don't use hacks in my work projects. I just show, that they do exist. What to do with them - you decide.
In my last two projects I moved the UI processing loop into a SubVI. Obviously I couldn't move the controls/indicators as well, they were left in the main VI. The buttons were (almost) all configured with latching mechanical action. So, in that SubVI when a button was clicked, it did not un-press itself, because it was contained in the main VI, not in the Event Structure of the SubVI. Then I used Latch Value private property, which allowed me to un-press the button. Honestly, it was a second or third time, when I used something from the attic instead of a conventional way.
I guess I wandered off in the weeds a little bit, my apologies. I can see exactly using your method to rest the button for a project where the UI loop was moved into a subVI - especially if you already have a whole bunch of buttons already. For new projects where I have already planned for this, I just create the control, change the mechanical action like I said, then just use a normal value property to reset it. Same concept, just a very slight difference in execution.
@billko wrote:
I just create the control, change the mechanical action like I said, then just use a normal value property to reset it. Same concept, just a very slight difference in execution.
Except that you should use a local variable here. Much more lightweight! 😄
About the original topic
Maybe I should remind all of you about my 12 year old idea posted here:
Allow unwired signaling properties to fire events
It addresses some of the concerns. (but read all the comments!)
(Defining the behavior in detail is a bit of a can of worms)
@altenbach wrote:
@billko wrote:
I just create the control, change the mechanical action like I said, then just use a normal value property to reset it. Same concept, just a very slight difference in execution.Except that you should use a local variable here. Much more lightweight! 😄
About the original topic
Maybe I should remind all of you about my 12 year old idea posted here:
Allow unwired signaling properties to fire events
It addresses some of the concerns. (but read all the comments!)
(Defining the behavior in detail is a bit of a can of worms)
I think we were talking about affecting controls in another VI.
@billko wrote:
I think we were talking about affecting controls in another VI.
Yes, this thread probably drifted all over the place in the last 12 years and that's why I specifically said "About the original topic ...". 😄
