Jump to content

Why doesn't LabVIEW Save All when I ask it to Save All?


Recommended Posts

In a typical software application, when you perform a "Save All" action you would expect it to save all of your open documents or working files, right? Not so in LabVIEW. Apparently LabVIEW is not a typical application. Even though I ask LabVIEW to please save all my VI's. It doesn't. I can see that it doesn't because when if I open up a VI that is on the diagram of another visible VI, I see an asterisk in the titlebar indicating that the VI has unsaved changes. In LabVIEW 8.5.1 there are two "save all" menu items, one called "save all" and another called "save all (this project)". I've tried both and neither produces the expected results.

It's possible that the behavior of the "save all" has changed over the last four or five LabVIEW versions. In the past, the "save all" menu function would save ALL vi's in memory. Regardless if the front panel is visible or not. I'm thinking that this is not the case anymore and now LabVIEW only saves VI's with their front panel visible. An exception to this rule is that LabVIEW somehow remembers if you've opened a VI with unsaved changes and then closed it (without saving changes) thus actually saving it when you later perform a "save all".

Is all of this true? If so, then is there any way to perform the old-style "save all"?

Link to comment

I'm so glad you mentioned this. I thought I was loosing my mind. During project development, I typically create a "Load All" vi to make certain that all components are loaded into memory and quickly available while modifying code. The Load All vi also serves (or at least it used serve well in previous versions of LabVIEW) as a quick and convenient way to detect vi's that need to be resaved due to either explicit or inexplicit modifications. By closing the Load All vi in previous versions of LV, I would be prompted to save vi's needing to be re-saved. Now, in LabVIEW 8.5, I cannot simply "save all" to flush all changes to disk, nor does LV 8.5 prompt for saving vi's which do not have their front panels open. Now I have to actually open all of the vi's front panels to be sure that they are fully opened in order to ensure they are all up to date. I mentioned this odd behavior to a colleague and he thought I'd been smoking something or functioning in some altered reality. I see now, it is not me, its LV 8.5

Thanks,

KT

Link to comment

No CARs have been filed matching the situation you describe. For the record, Save All should save all VIs in memory in all projects. Save All (this project) should save everything currently in memory in this project (note: it won't load VIs from disk that aren't in memory but are listed in the project). Any deviance from this behavior is a bug.

I've just run through a bunch of "Save All" tests on a few different hierarchies and I didn't see any problems. Is there any thing special about the particular VIs that aren't being saved? Can you post a set of VIs that demo the bug?

QUOTE (kevintho @ Jul 8 2008, 09:17 PM)

nor does LabVIEW 8.5 prompt for saving vi's which do not have their front panels open.
I know this isn't true. I rely on that every day, and it works just fine... a VI need not have its panel open to generate the Save Changes dialog. Now, if you load a VI using Open VI Ref and then close the ref, you won't be prompted, but straight up closing the panel will indeed throw Save Changes.

Again, if you can post a VI hierarchy that demonstrates the bug, it would be most appreciated.

Link to comment

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.