PopUp VI Hanging at Event Structure

[Pranay_c]

@RavensFan, i am able to replicate the issue again and again in my PC

[Pranay_c]

@billko , the timeout case i am using just to wait for the user to give his input and click on login, Actually this popup will be called from another event structure and i would like to point out that i have many VIs running in parallel, each having event structures and user events tied with it.

[Pranay_c]

@jeff , i dont have anything in the timeout case

[billko]

---

@Pranay_c wrote:

@billko , the timeout case i am using just to wait for the user to give his input and click on login, Actually this popup will be called from another event structure and i would like to point out that i have many VIs running in parallel, each having event structures and user events tied with it.

---

So then you just turned this event structure into a polling loop?  Get rid of the timeout case and let the event structure wait for the user event.  If you do this for all your dialogs, it would seem to me that you have an incomplete understanding of event structures.

[JÞB]

---

@Pranay_c wrote:

@jeff , i dont have anything in the timeout case

---

Then why do you execute it?  Remove it.. you might have even found an edge case flaw in the optimizer.  Where it only partially removes the dead code that executes faster than your user can react.

[billko]

Also, I am going to resurrect part of my original, unedited comment concerning filtering the panel close event.  the way you have it right now, the front panel will close right away - before you get to execute whatever is in the false case (which happens to be nothing at the moment).  To prove this, place a one-button dialog box in the false case and close the running VI via the [x] button.  The one-button dialog never executes.

The proper way to handle this is with the filtered event - i.e., "panel close?" - discard the event, and close the VI manually, using the FP.Close method as the last thing you do in the VI.

[richjoh]

I'd recommend you use Event Viewer, I think its under Labview main menu  _View\_Event Inspector Window. This will show you what events fired and whether or not they are handled. I found this to critical to troubleshoot events as you build regular, filtered or dynamic events. Just break points alone won't troubleshoot event handling.

My 2 cents...

Rich J

[Mads]

The attached code does not contain the app launch VI, have you verified that the code is not stuck there when you press the login button? (To test that turn on execution highlighting and you will see the Launch App VI with an arrow overlay icon it if it is stuck there...)?

If the code is run without that it seems to be working fine.

As many has said here there is no need for the timeout, that should not cause an issue here though.

(Perhaps you were using it earlier to get updates from the controls with them login event case -instead of having value change events for each of them? That's a lazy solution that I guess many of us use now and then when we do not want to bother with creating the separate event cases. Newbies (or oldies too used with the pre-event case versions of LabVIEW...) use it as well like that to get updated values from the controls, not having fully understood the event structure yet.)

[wiebe@CARYA]

Who shows the front panel of the VI? 

If the VI is set to modal, and the VI in on the diagram of a running VI, it will block if the front panel is opened for any reason. It could be a problem of the VI calling the popup, for instance if that VI opens the front panel and doesn't (always) close it.

Or if the VI was open to begin with. So when the VI is open (maybe 1/5 times?) and you run your main, the VI is started, but it won't close automatically, because it was open to begin with.

You might have better luck with a "manual" VI Server Open\Close of the front panel.