window events infinite loop

[altenbach]

OK, we need some "destructive testing" doing a tear-down. 😄

Save your toplevel VI under a different name and then delete everything except the outer while loop, the event structure with the tune case, the case structure in it, the inner while loop, the delay, and the "tune boolean".

Can you still reproduce the problem? If so, attach the VI.

[dgholstein]

Raven;  The only downside is I don't have a way to catch the close window signal when I'm looping.  Is there a way to catch that signal within (as opposed to with) an event structure?  A test operator is all too willing to X-out an application without going through a formal turn off sequence (the button is there, and it works with Word and Paint).

[TCPlomp]

Yep you can:
I am now going to give the worst advice ever given on event structures

A second event structure inside the Tune=True case with two frames:

• Timeout (0 ms)
• Panel close

Ton

[dgholstein]

Are you sure I won't be arrested by the LabView police?  The same ones who won't allow us to break out of a "For Loop" when encountering an error (like when an operator unplugs a USB, or turns off connected equipment)?

There should be a way to simply check for a "Panel Close" event rather than using the Event Structure.

[RavensFan]

You can also go into the VI properties and disable the X button.  Also use the Panel Close? filter event.  Discard the event, but use the fact that it ran to queue up your shutdown functions, then close the program.

[TCPlomp]

---

@dgholstein wrote:
Are you sure I won't be arrested by the LabView police?  The same ones who won't allow us to break out of a "For Loop" when encountering an error (like when an operator unplugs a USB, or turns off connected equipment)?

There should be a way to simply check for a "Panel Close" event rather than using the Event Structure.

---

Dan,

you will (most likely) not get arrested, it should work, because that's how the event structure is designed, and it is a rather simple check.

I can think of only one reason for this apparent bug (setting FP-lock on one event, also influences other evetns):
You mention DLL's, since they are placed inside VIs that are inside the main GUI VI they run most likely inside the UI thread.
That might blocking any thread messaging, and maybe LabVIEW is the one that locks the FP internally is a locking FP event happens.
Since the LabVIEW UI thread is locked the OS might be locking parts of the GUI where LabVIEW has registered events for.

Ton

[dgholstein]

I can think of only one reason for this apparent bug (setting FP-lock on one event, also influences other evetns):
You mention DLL's, since they are placed inside VIs that are inside the main GUI VI they run most likely inside the UI thread.
That might blocking any thread messaging, and maybe LabVIEW is the one that locks the FP internally is a locking FP event happens.
Since the LabVIEW UI thread is locked the OS might be locking parts of the GUI where LabVIEW has registered events for.

Ton

---

Ton;

It also happens with the stripped-down example I posted, demo.vi.  There are no DLL calls there.

Thanks,
   ...Dan

[altenbach]

---

It also happens with the stripped-down example I posted, demo.vi.  There are no DLL calls there.

---

Your demo works perfectly fine in LabVIEW 8.5.1, even with other events set to lock the panel.

Obviously, you run into an old bug that has been fixed in later versions. You are still running 7.0, which is ancient! Time to upgrade! 🙂