Is it possible to programmatically save all?

[GregFreeman]

Does anyone know if there is a method available to do "save all" just like you would from the project? Or do I have to get all the VIs from the project recursively, myself? I don't see a method for it from invoke nodes wired up to a project reference. Just trying to avoid reinventing the wheel.

[JÞB · Accepted solution]

Should do

[GregFreeman]

Found this on LAVA

Edit: woops, jeff beat me to a solution

[JÞB]

Makes me curious... is that BD open ?

[GregFreeman]

---

@JÞB wrote:
Makes me curious... is that BD open ?

---

Which BD? Also, I will be using a method to open a project reference which this VI doing the saving is not in. So, I won't have a static project reference in my code and this VI won't be saving itself using this method, since it won't be executing the save all on the project which contains it (if that's what you are getting at).

Edit: Darren suggested I load the main VI's into memory first, because this VI has no caching and tries to open each library/VI individually, save, then close. But, even when doing so this method is crawling. It takes upwards of 5 minutes to save the 700 VIs in the array. But, if I close the project and it says "you have 108 unsaved VIs" and I press save, it takes about 3 seconds to save them all. Suggestions on this?

[JÞB]

---

@for(imstuck) wrote:

---

@JÞB wrote:
Makes me curious... is that BD open ?

---

Which BD?

The Lava Link-  I was mobile last night and couln't look into this

Seams to be open

As too the LAVA Code working slowly.  I would guess that a "Defer FP Updates" might help a bit around this code since this VI is going to hog the UI Thread.

Migrating the Loop invarient constant "Not a Refnum" outside the case in the loop may help too. (Just guessing with the compiler optomizatione but I don't think it will auto-migrate from inside the case)

A CLF node pointed to the right call in LabVIEW.dll is another possibility but I would urge extreeme caution! (This path I fear to tread without a very good backup)

[GregFreeman]

---

@JÞB wrote:

---

@for(imstuck) wrote:

---

@JÞB wrote:
Makes me curious... is that BD open ?

---

Which BD?

The Lava Link-  I was mobile last night and couln't look into this

Seams to be open

---

OHHH, like open source, not physically open on my machine. Yes, and in fact it ships with LV 2012, but I have to use 2011 in this case, so I used the VI linked there.

[JÞB]

After some more thought....

A few edits to the referenced code.

• changed error merging to outside the loop
• migrated Not A refnum and library VI server constants
• Wired error through all cases (No more look-ups for the default error cluster def inside a loop)

Should speed it up by some (Try it and post results if you can)

A "(VI,Library)" wired to the project Item type filter may also help by reducing the size of the auto indexed array.  but the Help is unclear as to how to get multiple filtered types.  I would need to play with it some

[Ben]

---

@JÞB wrote:

---

@for(imstuck) wrote:

---

@JÞB wrote:
Makes me curious... is that BD open ?...

As too the LAVA Code working slowly.  ...

---

Saving from the bottom up* used to help with the saves.

Ben

* Bottom up = The VIs with no dependacies get saved first then the VI above them and work you way up the hierachy.

[Ben]

Prior to the Project being introduced I had a need to "Clone" a complete VI hierarchy and add a prefix to the names etc. The get the lniinking right I had to save from the bottom working my way up.

The attached zip has the VI I used back then.

The code is attrocious I am sure but when last I tried it, it worked.

It may give a an idea on how to do the bottom up save.

Ben