Question about closing a dialog that is open by mistake, freezing program

[altenbach]

I think it should be up to LabVIEW itself to automatically close the panel (defer changes) of any "modal, open when called & close when done" subVIs that are open in edit mode when the toplevel VI is run. 

If the panel is open, the "close when done" should simply also trigger when the subVI switches from edit to run mode. (i.e. we are "done" editing!)

That would avoid a lot of grief. 😄 

Is there an idea already?

[JÞB]

---

@altenbach wrote:

I think it should be up to ...

That would avoid a lot of grief. 😄 

Is there an idea already?

---

Yes,  I am fairly certain that there is an idea.  Look into the "Declined " ones.

Maybe YOU could take another run!  MY IDEAS either get implemented without attribution and Declined or,  just ignored.

Of course,  that was a decade ago when "Revolke All Modals.vi" by DNatt was in vogue....and that vi DID ACTUALLY  rewrite that vi property...under-the-hood so that ALL your dialogs stopped being modal.

BAD, BAD, BAD!

[JÞB]

See Here! 

[altenbach]

---

@JÞB wrote:

See Here! 

---

Wow, that's terse! I have a hard time to even see the connection to this thread. 😮

[JÞB]

You should look at the 1st comment!

I've been pissed for 20 years

[altenbach]

Ah, ok. Wasn't sure about the exact definition of "idle" state. It that similar to "reserved"?

As a graphical programmer, I am not very good with words. How many states are there? Is there a table?

[JÞB]

---

@altenbach wrote:

Ah, ok. Wasn't sure about the exact definition of "idle" state. It that similar to "reserved"?

As a graphical programmer, I am not very good with words. How many states are there? Is there a table?

---

In this context.  Idle state means exactly that.  The state of the vi

[wiebe@CARYA]

---

@JÞB wrote:

---

@altenbach wrote:

Ah, ok. Wasn't sure about the exact definition of "idle" state. It that similar to "reserved"?

As a graphical programmer, I am not very good with words. How many states are there? Is there a table?

---

In this context.  Idle state means exactly that.  The state of the vi

---

If a VI is in state idle, those properties (modal\floating) aren't used. Some toolbar properties are (like show abort and continuous run).

Those properties are only applied if the VIs state is running or running top level.

It is often assumed a modal VI that blocks is in ide state because it's not executing, but in fact it's state is 'running'.

Spoiler

This SubVI is obviously not executing anymore when it's state is queried:

Yet it's state is 'running'.

It's properties will be applied, as it's not idle...

So, AFAIK, the idea is to make things exactly as it is.

I do agree the blocking modal VIs are inconvenient, but there are use cases too.

[Yamaeda]

---

@DBISI wrote:

Hello,

I have a few VI's in my application that I have configured as Dialog boxes. If I have them open by mistake when my main VI is running during debug, they take over and prevent me from doing anything. Alternatively, if I attempt to debug them and probes are installed on them, when the dialog completes and begins to "close" it stays open and does the same thing. The only thing I find that works to regain control is ctrl+alt+delete the program to death and restart it. Ctrl+. doesn't work nor can I change VI windows. It's not a critical issue as the VI's work as intended, its just annoying and would like to know if there is a trick to fix it.

Is there a way to force those VI's to close? Or prevent this behavior? I presume not.

---

If you do manage to lock yourself out of the code in this way (and we all have, many times), Kill'em'all can be quite helpful (autorun)

[DBISI]

Thanks for the feedback. I'm gonna look into implementing some modifications today or tomorrow.

Kill'Em'All looks promising. But I am not sure how to run the VI when a dialog has taken complete control...

Thanks.