Save As... on running VIs

[Jim Kring]

Starting in LabVIEW 8.0, the File>>Save As... menu option was disabled on running VIs. However, you could still open a VI Server reference to a running VI and invoke the Application.Save method to effectively perform a Save As operation. Now, in 8.2, it is no longer possible to invoke the Application.Save method on VIs that are running in any application instance, including NI.LV.Dialog, which is used for VI launched by the menu (Tools menu, for example). Attempting to do this in LabVIEW 8.2 produces an error (Error 1507. Possible Reason(s): LabVIEW: Cannot change the name or path of a VI in its current state. Method Name: SaveInstrument). I have to wonder whether there was some good reason for this (besides protecting us from ourselves). This new limitation actually prevents some cool things that we were doing with OpenG Builder -- specifically, its ability to build parts of itself at first launch.

[LAVA 1.0 Content]

Starting in LabVIEW 8.0, the File>>Save As... menu option was disabled on running VIs. However, you could still open a VI Server reference to a running VI and invoke the Application.Save method to effectively perform a Save As operation. Now, in 8.2, it is no longer possible to invoke the Application.Save method on VIs that are running in any application instance, including NI.LV.Dialog, which is used for VI launched by the menu (Tools menu, for example). Attempting to do this in LabVIEW 8.2 produces an error (Error 1507. Possible Reason(s): LabVIEW: Cannot change the name or path of a VI in its current state. Method Name: SaveInstrument). I have to wonder whether there was some good reason for this (besides protecting us from ourselves). This new limitation actually prevents some cool things that we were doing with OpenG Builder -- specifically, its ability to build parts of itself at first launch.

I think the following workaround should do the thing:

- Write an independent VI (SAVE.vi) that can handle saving of the project

- Start main VI, if you want to build the project

- dynamically create a copy of SAVE.vi and all the VIs that you need for saving process (easiest is to use a library and call save as method)

- call the transient copy SAVE.vi with state parameter that describes in what state your progrman was prior to build, don't wait it to exit

- exit everything else

- SAVE.vi builds the project and re-executes the main VI

- delete transient copy of SAVE.vi

That's it, quite complicated compared to your previous solution, I admit.

[Aristos Queue]

Starting in LabVIEW 8.0, the File>>Save As... menu option was disabled on running VIs. However, you could still open a VI Server reference to a running VI and invoke the Application.Save method to effectively perform a Save As operation. Now, in 8.2, it is no longer possible to invoke the Application.Save method on VIs that are running in any application instance, including NI.LV.Dialog, which is used for VI launched by the menu (Tools menu, for example). Attempting to do this in LabVIEW 8.2 produces an error (Error 1507. Possible Reason(s): LabVIEW: Cannot change the name or path of a VI in its current state. Method Name: SaveInstrument). I have to wonder whether there was some good reason for this (besides protecting us from ourselves). This new limitation actually prevents some cool things that we were doing with OpenG Builder -- specifically, its ability to build parts of itself at first launch.

Doing "save as" on a running VI has always been an thread-unsafe operation. The fact that it has worked so often in the past is the Grace of God and the fact that few users have dual CPU or multicore CPUs. With the introduction of LVClasses, we had a situtation that where runtime save as would almost always crash. Couple that with the increased number of dual core and dual CPU machines, and it was more than time to do something -- either prevent runtime "save as" or make "save as" be thread safe. The latter would be preferrable from your point of view but it turned out to be technically infeasible when a couple of developers investigated it. So the error.

[Chris Davis]

...in LabVIEW 8.2 produces an error (Error 1507. Possible Reason(s): LabVIEW: Cannot change the name or path of a VI in its current state. Method Name: SaveInstrument).

Is there a work around for this issue. I have beta 7 of the OpenG Builder and LV 8.2