FP Button not responding - very strange behaviour

[GIC-SAGM]

Please take a look at the attached vi.

The intent is to provide guidance through a sequence of steps. The last step presents a "Done" button instead of "Next".

The next button "floats" in front of the tab control. I make it 'disappear' when displaying the last tab so that the "done" button comes into play.

The trouble is that the done button does not act on / react to clicks when it gets displayed so the vi just hangs and never terminates - I have to shut it down the 'strong' way.

Why??? 

I almost feel embarrassed, this looks like a "newbie trap", and yet I have been around for some time now... 😲

[altenbach]

Because you fire a signaling event for the tab control but exit that loop and the event cannot trigger, but the event is set to lock the front panel until it can complete. Catch 22.

There are many other things wrong with this, I'll make a quick list later.

[johntrich1971]

I don't have LabVIEW on this machine so can't look at your code, but the question that immediately came to mind is how are you making the floating Next button disappear? My guess is that this button is on top of the Done button. If this is the case then you would need to rearrange the buttons for the Done button to work.

Another option would be to just change the Text on the Next button to Done using a property node and use the same button.

[altenbach]

---

@altenbach wrote:

There are many other things wrong with this, I'll make a quick list later.

---

• You manipulate the tab control exclusively via signaling value properties. Make it an indicator and keep the value in a shift register.
• Create an event for the done button, no need for that tail loop.
• Why have a timeout case if it is not used?
• etc. etc.

Here's a dramatically simpler VI that does exactly the same thing!

Maybe it can give you some general ideas how do do things less convoluted. Many improvements are still possible.

[altenbach · Accepted solution]

Note that your "string" (I can probably come up with a better name!) could just be a decoration on that tab.

And, as has been mentioned, you could just change the boolean text of the button. and get rid of the done button entirely.

[altenbach]

---

@altenbach wrote:

And, as has been mentioned, you could just change the boolean text of the button. and get rid of the done button entirely.

---

Here's how that could look like:

Now all we have is one single event! (Note that incrementing an enum (or tab) wraps around at the end.

[GIC-SAGM]

Thank you Altenbach.

Agreed, I "too much convoluted" something that is simple and does have a simple solution.

Some comments:

@altenbach wrote:

And, as has been mentioned, you could just change the boolean text of the button. and get rid of the done button entirely.

I initially did use only one button - and everything worked fine - but I did not like to give the operator the "same visual queue" when the guidance terminates by changing only the 'words' on the button. Because the operator moves from "set-up attitude" to "production attitude", I preferred to "underline" that behavioral change with a different button altogether.

This is what got me in trouble! 😋 😎

My 'big rookie mistake' was failing to see I was triggering an event via the signaling property node that would hang on the queue since the loop was going to stop!.... 😩