Modifications to VI are lost if there is a panel close filter event

[AbandoningCausality]

I'm not sure if this is expected functionality but if you:

• Have an event structure with a panel close filter event with a false constant wired to the discard terminal
• Run the VI
• Close the panel
• Select "Cancel the close operation"

Any VI changes you made will not be saved. You will likely lose some work. I recomend either hiding the cancel button or closing the VI front panel but keeping it in memory when this happens.

[mikeporter]

Yes, this is expected. If you have outstanding changes when you programatically close the VI you will lose the changes. But why do you have a filter event with a false constant wired to discard? You just sacrificed the reason for having a filter event.

Typically people will wire a true to disable, stop the event loop and let the VI stop on its ow.

Mike...

[AbandoningCausality]

I guess my question would be why have two options in the save dialog that do the same thing (Cancel and Don't Save). As to why I wired a false constant, it was a mistake. I forgot to set it true.

[JÞB]

---

@AbandoningCausailty wrote:

I guess my question would be why have two options in the save dialog that do the same thing (Cancel and Don't Save). As to why I wired a false constant, it was a mistake. I forgot to set it true.

---

You cancled the save . Not the close event. The prompt is part of the close event you must process since you wired a false constant.  but, you cannot save a running vi!  Your choices then are restricted to cancel or dont save and close anyway out of the three that dialog supports.  

True---Cancel makes no sense since the close event is in progress and will complete but,  it makes even less sense to discard the filter event.  Could NI save us from ourselves?  Yup, the return on investment is zero. This is developer training not user of product facing poor behavior.  Write yourself a VIA test (and use it) to prevent you from doing that foolish mistake again if the lost work pain is not enough motovation to write code free of that bug more often than not.

This falls into the class of bugs (and i admit it is undesired behavior to offer the Cancel under these unusual conditions) that makes software development so frustrating at times.  "The more foolproof you write the code....some fool will use it". Genius is limited, man's falibilty is not.

[crossrulz]

---

@JÞB wrote:

The prompt is part of the close event you must process since you wired a false constant.  but, you cannot save a running vi!  Your choices then are restricted to cancel or dont save and close anyway out of the three that dialog supports.

---

Not quite.  The filter event is for the Panel Close, not VI close.  You can close the front panel of a VI and is still running.  This save dialog is coming when the VI stops running.  So when the VI stops running and the panel is closed, the VI is closed out.  This is when the save dialog is coming up.

So when you hit the Cancel, that save operation is aborted and we go back to having an open VI, right?  But the panel is closed and it is not running, therefore the VI should be closed.  Hey, you just ran into a possible infinate loop.  So the cancel button can't really work in that situation.

One fix NI could possibly do is reopen the front panel when the cancel is selected.

[Oligarlicky]

---

@JÞB wrote:

---

@AbandoningCausailty wrote:

I guess my question would be why have two options in the save dialog that do the same thing (Cancel and Don't Save). As to why I wired a false constant, it was a mistake. I forgot to set it true.

---

You cancled the save . Not the close event.

---

Then the label for "Cancel" is wrong. The label says "Cancel the close operation"