Jump to content
Thoric

Silently close a scripted VI with unsaved changes

Recommended Posts

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 by Thoric

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
Share on other sites

Darren: This is all programmatically.

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

Share this post


Link to post
Share on other sites

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.

 

post-4441-0-39595100-1387474487_thumb.pn

Share this post


Link to post
Share on other sites

Try adding the object after you show the BD.

 

Nope, still not prompted:

 

post-4441-0-16736800-1387478285_thumb.pn

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

 

 

  • Like 2

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites
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>

 

attachicon.gifSuppress Dialogs.vi

Darren, can you make a 2012 version f this?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Description or fact?  :P .

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 by flarn2006

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.