Simple way to clear a VI Undo History?

[Thoric]

I want to clear a VI's undo history, programmatically, from another VI. I see in 2013 that saving doesn't clear the history, so my original plan to simply save my target VI somewhere isn't working. Is there a scripting technique that will obliterate the undo history?? A quick search didn't find anything.

Edited March 26, 2014 by Thoric

[Darin]

Changing the password erases the undo history.

[Thoric]

Thanks Darin. I'll try that. Presumably if I take my target VI, apply a password, remove the password, I'll find the undo history is blank and the VI remains unprotected. Cheers!

 

Edit: it seems LAVA now thinks I'm no longer "Thoric" but "Riggy" !?

Edited March 26, 2014 by Riggy

[Thoric]

Changing the password erases the undo history.

 

I can't get this to work programmatically.

 

If I manually set a VI's protection to password-protected through the VI Properties window, then unprotect it again, I see the Undo history is emptied.

 

However, if I programmatically invoke LockState.Set with Password-protected, then invoke LockState.Set with Not Locked, the VI undo history remains in tact.

Inserting a Save.Instrument makes no difference either. The Undo history always persists! Any thoughts anyone?

 

Below is a snippet of some example code that attempts to prove that password protection of a VI clears the undo history. It creates a new VI, uses a Windows API call to simulate a standard window move operation as normally performed by an operator, then sets and unsets a password to clear the undo operation but it remains intact.

 

(I will get the snippet up here once I figure out how!)

[Thoric]

Snippet included as an attachment, rather than an image.

[Darren]

If you drop a dummy object on the diagram, then delete it, without wrapping those operations in a Begin Undo/End Undo transaction, it looks like it clears the Undo history.

[Thoric]

If you drop a dummy object on the diagram, then delete it, without wrapping those operations in a Begin Undo/End Undo transaction, it looks like it clears the Undo history.

 

How bizarre! Yes, that works. Dropping a simple ADD function, then deleting it, vaporizes the Undo History. Any thoughts as to why? Can LV not cope with changes that aren't wrapped in an Undo transaction?

[Darren]

That's right. When you're scripting, you need to use the Undo transaction methods in order to preserve (and add to) the Undo history.

[Sparkette]

Forgive me if I'm missing something, but wouldn't simply closing and re-opening the VI also do the trick? Or is the undo history actually saved in the VI file unlike most programs' behavior?

[Thoric]

My need is to clear the "Window move" undo entry, which I'm programmatically doing after loading the vi. Hence I needed to wipe the undo history programmatically too.

[Jim Kring]

I'm looking for a way to change a visible state of a Case Structure, and (A) not have this show up in the Undo Transaction history and (B) not wipe out the undo history. Right now, if I don't create an undo transaction for the visible frame change, it wipes out the undo history :-(

[Darren]

1 minute ago, Jim Kring said:

I'm looking for a way to change a visible state of a Case Structure, and (A) not have this show up in the Undo Transaction history and (B) not wipe out the undo history. Right now, if I don't create an undo transaction for the visible frame change, it wipes out the undo history :-(

I don't know of a way to accomplish this. As discussed above, changing a VI with scripting requires the Transaction methods to preserve Undo history. To my knowledge you can't modify a VI with scripting, have that modification not show up in the Undo history, but preserve the previous Undo history.