How to prevent a terminated Sub-Panel VI from blocking the rest of the application?

[maflAT]

Hello,

I have a little test VI with that launches 2 sub VIs inside a sub panel.

This works perfectly fine, with each VI receiving GUI events independently of each other.

What I'm unsure about is the optimal way to handle the termination of a sub VI.

Without any further action, a terminated sub VI will stay visible inside the panel with no indication to the user, that it is no longer running. At this point, the rest of the application is still running fine.

But as soon as you click a button in the terminated sub VI, the other sub VI and the top level VI will become unresponsive.

My current solution is to poll execution state and remove the sub VI from the panel if the state changes from "Run top level" to "running".

I'm not happy with this solution for the following reasons:

• This does not work when launching sub VIs via start asynchronous call. It seems like asynchronously running VIs are always in execution state "running".
• In some situations I might prefer to keep the sub VI visible and just block it from receiving inputs.
• I have to poll execution state.

Other things, that I tried:

• Calling "Front Panel.Close" from the sub VIs exit code and from the top level VI.
  -> This seems to have no effect. I guess the FP is technically already closed.
• Calling "Abort VI" from the sub VIs exit code and from the top level VI.
  -> Raises error 1000.

How do you guys handle this situation?

Is there a clean way to handle this without setting up some explicit communication between the top level and sub VIs?

My perfect solution would be if I could just call "Front Panel.Close" or something equivalent to "Ignore GUI events" in the sub VIs exit code.

 

 

[JÞB]

How do you guys handle this situation?

---

I use a queue, notifier or dynamic event.

Is there a clean way to handle this without setting up some explicit communication between the top level and sub VIs?

---

No.  You can try some of the things you already tried but, those aren't really "clean." 😉

Why are you trying to avoid some state information exchange between the subpanel parent and child? They are related by dispatch.  Think of it like making a phone call to your mother to let her know how you are doing.  EVEN more importantly,  mom is going to find out anyway so, it's best to hear it from you first. (It saves her a lot of aggravation trying to figure out what you are up to now)

[maflAT]

---

Why are you trying to avoid some state information exchange between the subpanel parent and child? They are related by dispatch.  Think of it like making a phone call to your mother to let her know how you are doing.  EVEN more importantly,  mom is going to find out anyway so, it's best to hear it from you first. (It saves her a lot of aggravation trying to figure out what you are up to now)

---

That's an interesting way of looking at it 😆.

I was just wondering if I was missing some obvious procedure. Not trying to avoid information exchange.

[JÞB]

Don't forget any pertainate termination state data.

Pass/fail. error, user abort, et cetera.

[Yamaeda]

I haven't used SubPanels much, but i'd use a User Event to send information 'upwards' that it's closing. Main VI can then remove it accordingly. Maybe you can send 'ThisVI' as data and use it as a general Close Panel function.

[maflAT]

---

@Yamaeda wrote:

I haven't used SubPanels much, but i'd use a User Event to send information 'upwards' that it's closing. Main VI can then remove it accordingly. Maybe you can send 'ThisVI' as data and use it as a general Close Panel function.

---

Thank's for the tip. I like this idea.👍