Silently close a scripted VI with unsaved changes

[Thoric]

I've used scripting (which I'm still learning) to create a New VI, create some objects, show the front panel and show the block diagram. Now I want to close the VI and lose it, but because it has unsaved changes I get a dialogue box asking if I want to save it. I've set the options input to New VI to 0x0, which means it shouldn't be marked as modified and it shouldn't prompt to save changes.

 

How do I close the VI silently? I have no interest in keeping the changes, so saving it first isn't what I want to do.

Edited December 18, 2013 by Thoric

[Darren]

Are you trying to close the VI interactively, or programmatically?

[Darin]

I typically save it in the temp directory and delete it. Not the most elegant, but scripting rarely is.

[Thoric]

Darren: This is all programmatically.

Darin: Thanks, I was beginning to wonder if I might need to do this.

[Darren]

What specifically are you doing to the VI to cause it to prompt on close? When I create a new VI and drop an object in it, I don't get prompted to save when I close the VI, even if I set up an Undo transaction.

 

[Darin]

Try adding the object after you show the BD.

[Darren]

Try adding the object after you show the BD.

 

Nope, still not prompted:

 

Here's the VI I'm trying (saved in LabVIEW 2013), if anybody wants to modify it in such a way that I get a prompt when the VI closes.

test script and close.vi

[Thoric]

I'm not at my PC today, but I am making a few winapi calls to the vi to change its parent. I'm kinda docking it in a container, so that must affect LabVIEW? I can modify your code tomorrow to mimic mine, most likely.

[Thoric]

OK, so this is where I'm at. Taking Darren's code segment above and slowly adding my own code to it until the Save Request issue arises, I see that it occurs as soon as I dock both the front panel and block diagram of the scripted VI into two individual containers. If I dock just one, or neither, LabVIEW doesn't ask me to save the VI when I close it.

By 'docking into a container' I mean changing the parents of the scripted VI windows, using a winapi call. My intention is to 'contain' these two windows to control their access from within my own environment.

 

I presume that once both the front panel and block diagram windows are re-adopted LabVIEW internally identifies unsaved changes?

[Darren]

I don't know anything about the internals of LabVIEW window management, so I can't speak to whether or not what you're seeing is intended behavior when the windows are reparented via winapi calls.

 

Here's a VI that may help, though. This password-protected VI (saved in LabVIEW 2013) calls a private VI Server property to suppress LabVIEW editor dialogs. Call this VI before you do your scripting, with a TRUE input. Then when your scripting is done, call it again with a FALSE input to reenable LabVIEW editor dialogs. <standard disclaimer here about using private LabVIEW functionality in production code>

 

Suppress Dialogs.vi

 

 

[Thoric]

Thanks Darren, this is an interesting function. Kudos for putting this together for me. 

[SDietrich]

Hi Darren,

 

I think you used the private application property App.UnattendedMode. This affects the whole application. Would the private VI property DoNotShowSaveChangesDialog do the same thing, but only for the VI in question? E.g. you don't have to remember to set it to FALSE after you closed the VI?

 

See this (password protected) VI (for LV 2010): NoSaveDialog.vi.

 

And of course: Don't let the QA guys catch you using this VI in production code!

[MikaelH]

I don't know anything about the internals of LabVIEW window management, so I can't speak to whether or not what you're seeing is intended behavior when the windows are reparented via winapi calls.

 

Here's a VI that may help, though. This password-protected VI (saved in LabVIEW 2013) calls a private VI Server property to suppress LabVIEW editor dialogs. Call this VI before you do your scripting, with a TRUE input. Then when your scripting is done, call it again with a FALSE input to reenable LabVIEW editor dialogs. <standard disclaimer here about using private LabVIEW functionality in production code>

 

Suppress Dialogs.vi

Darren, can you make a 2012 version f this?

[ShaunR]

See this (password protected) VI

 

Description or fact?   .

[hooovahh]

Darren, can you make a 2012 version f this?

As mentioned before this is just the App.UnattendedMode property node in a subVI, and the other VI posted is just the DoNotShowSaveChangesDialog property on a VI reference.  Turn on the super secret key to get these properties.  Here is one method.

[Darren]

Darren, can you make a 2012 version f this?

 

Sure, here's a version that can be used in LabVIEW 8.0 or later.

Suppress Dialogs.vi

[Sparkette]

Description or fact?   .

Description, I guess. I was able to unlock it just fine with that hex hack. If you want to make it yourself, just set SuperSecretPrivateSpecialStuff=true in LabVIEW.ini, place an Application property node, and select the Application->Unattended Mode property. That's exactly what Darren's VI does.

Edited August 22, 2014 by flarn2006

[hooovahh]

If you want to make it yourself, just set SuperSecretPrivateSpecialStuff=true in LabVIEW.ini, place an Application property node, and select the Application->Unattended Mode property. That's exactly what Darren's VI does.

The typical disclaimer to be said is that using this INI key enables private functions of LabVIEW which NI does not officially support.  Using any of these private functions means you are more or less on your own.  Support for these functions is non-existent, documentation is non-existent, and these functions may change from version to version without mention in a change log.

[Rolf Kalbermatter]

The typical disclaimer to be said is that using this INI key enables private functions of LabVIEW which NI does not officially support.  Using any of these private functions means you are more or less on your own.  Support for these functions is non-existent, documentation is non-existent, and these functions may change from version to version without mention in a change log.

 

And they may not just change to the better but introduce bugs in never versions, since they are not tested in the normal daily build tests and the internal tool that used them may have been removed or changed to use other functions. They also suddenly can be unimplemented, since as far as NI is concerned they never were documented so removing them is not something they would avoid at big costs when they clean up unused code.

 

As said by AQ and others on various occasions a large internal project is currently to rewrite substantial parts of LabVIEW to get rid of old legacy code that doesn't match the current coding standards anymore and in the process of this it is likely that a lot of old undocumented features will get axed while they are at cleaning up the code, if they are found to be either incompatible with the new architecture or unused by any of the current internal LabVIEW tools.