Problem Using Value(Signaling) with Latching Boolean ver 2017(sp1)

[jamiva]

I searched and couldn't find an answer to my problem. What I am trying to do is to exit a subVI by allowing the user to click either the "exit button" or the "Panel Close".

I have some housekeeping code in the Exit case that needs to be done regardless which button the user clicks. So when the user clicks the Panel Close, I wire a True to the Discard? event filter and use Val(Sgnl) to generate an event to execute the Exit case. This worked just fine in LabVIEW versions 2016 and prior. I tried to do this in ver 2017 (sp1) and it doesn't seem to work.

In 2017(sp1), the Val(Sgnl) Data Type is now Variant Data. When I try to write to the property, nothing happens. The property throws an error and NO event is generated. The help file says that you cannot READ from a latched Boolean. Doesn't mention anything about writing to a latched Boolean. What do I need to do different to get this to work in ver 2017. I guess I could create a dynamic event, but the old way was a lot easier.

[pincpanter · Accepted solution]

You are wrong. This property was never allowed for latching booleans.

Change to switching and reset the boolean by code when required.

[Mancho00]

---

@pincpanter wrote:

You are wrong. This property was never allowed for latching booleans.

Change to switching and reset the boolean by code when required.

---

You are correct that it was not allowed, but occasionally (rarely) it would work, although I can't recall how or why.  One way I got around it in LV2016 was to typecast the latched bool to a switched bool.  This doesn't work in LV2017, though.

[aputman]

Please have a look into a proper state machine architecture.  With that kind of setup, both events (button press and panel close) would redirect to an Exit state to run the cleanup code.  And if you decided to add a third method for exiting the program or if you have a critical error that requires program to exit, it's easy to do this by redirecting to the Exit state.  I'm assuming that your cleanup code is located within the Exit button event because otherwise, there would be no need to force that event to occur thru property nodes.  My suggestion is to keep the event structure very simple and mostly free of code so that it is free to process UI events. 

Spoiler

You might want to check out the JKI State Machine template.

[pincpanter]

I was not aware of this trick. I find it a little dangerous, though. There must be a good reason why latched boolean cannot be read/written by code.

However, it is not necessary to do a hack, as a straightforward workaround is available.

[altenbach]

Put all your cleanup code in the "panel close?" event and eliminate the exit button completely. One way to close the program is sufficient. Everybody knows the functionality of the [X] in the upper right corner, so that's the preferred and standard way.

A typical windows program does not have an [Exit] Button in some random location of the panel. It's not natural to have one. It just wastes valuable panel space.

[jamiva]

---

---

I was wrong. You are all correct about not being able to use the Val(Sgnl) on a latched boolean. I should have looked closer at my old code.

The old code used TWO booleans and both were specified for the Exit event: one was latched (visible to user), and the second was switched (hidden from view). But it was the switched boolean that I used with the Val(Sgnl). Learned my lesson. Next time I won't use similar names for two different controls: "Exit(button)" and "Exit"

altenbach: It wasn't my idea to have two ways to exit the popup window. I originally had one, but got overruled.

Thanks for all your help

[altenbach]

---

@jamiva wrote:

---

altenbach: It wasn't my idea to have two ways to exit the popup window. I originally had one, but got overruled.

---

OK, I wasn't aware that this is a popup, and yes, if the specs require something, you have no choice. 😞

Typically a popup has an OK and cancel button, [OK] tied to the enter button and [cancel] tied to the escape button. Pressing the [x] should be equivalent to cancel.

Of course functionality can differ significantly. 😄

Back to the original problem, there is also this old idea, of course.