Saving a Class with Unsaved Members

[jgcode]

[cross-posted to ni.com]

Howdy

This may be a VI Server question more so than a scripting one?

But any help is much appreciated.

I am running into the following issue:

I have an unsaved Class with unsaved members that I want to perform a Save All on.

If I run the LVClassLibrary.Save method first I get the following error:

Error 1019 occurred at Invoke Node in *.viPossible reason(s):LabVIEW:  One or more untitled subVIs exist. This file cannot be saved until all dependent files have been named.

If I try to save each member first using VI.SaveInstrument I get the following error

Error 1450 occurred at Invoke Node in *.viPossible reason(s):LabVIEW:  One or more untitled library dependencies exist. This file cannot be saved until all dependent files have been named.Method Name: Save:Instrument

I can't seem to find a method that does everything all at once.

And I can't seem to do either one first.

Can anyone help?

Cheers

-JG

[Aristos Queue]

Try just setting the VI.Path property without calling Save, then call save on the Library, then call save on the VI. If that doesn't work, I think the GOOP Toolkit from Symbio does it by removing all the VIs from the library, saving the library, then adding the VIs back and saving again.

[MikaelH]

Yes, that's right. First I create an Empty lvclass, and I add and save the methods.

[jgcode]

Thanks guys.

The VI.Path property is not writable - so I will have to pull out the VIs, Save them, then put them back.

Just out of interest - is there a Private Method to do this - surely you guys at NI don't have to do it this way?

To really push my luck - any chance of creating a wrapper for it?

What I am trying to do is essentially recreate the Save Class Dialog, and handle unsaved members etc...

Everything was going great until I got to the last bit to do the save

Oh well, maybe I should have taken DFGray's advice and just enforce that the Class is saved.

[jgcode]

Thanks guys

I just tested it out and it works ->

For All Unsaved VIs:

>> VI.DisconnectFromLibrary

>> ProjectItem.Delete

LVClassLibrary.Save (now works)

For All Unsaved VIs:

>> ProjectItem.AddItemFromMemory

>> VI.Save.Instrument

LVClassLibrary.Save (save with all members)

The only issue with the above is that I am currently doing a recursive search for all Project Items in the Class which flattens the Project Item hierarchy as it returns an Array of (Unsaved) Children.

This means when I add the files back they appear directly under the Class, not in their original location i.e. they may have been nested in a virtual folder.

But I could fix this up by integrating the above into the recursive search.

[jgcode]

Here is a screenshot of what I did if anyone else is interested

[Aristos Queue]

The VI.Path property is not writable - so I will have to pull out the VIs, Save them, then put them back.

Just out of interest - is there a Private Method to do this - surely you guys at NI don't have to do it this way?

You're right, we don't, but it is all in C++ code. Never had anyone ask for it before, believe it or not.

To really push my luck - any chance of creating a wrapper for it?

Unlikely at this time.

What I am trying to do is essentially recreate the Save Class Dialog, and handle unsaved members etc...

That's a massively non-trivial task, as in, it took 4 months and four LV developers to get it working for all the various use cases when we rewrote it in LV 8.0.

Everything was going great until I got to the last bit to do the save

Funny... that's what we said about LV 8.0.

Oh well, maybe I should have taken DFGray's advice and just enforce that the Class is saved.

Yes. Your time will be better spent.

[jgcode]

That's a massively non-trivial task, as in, it took 4 months and four LV developers to get it working for all the various use cases when we rewrote it in LV 8.0.

Well I did my version over 2 days...

Do hacks count?

[Aristos Queue]

Well I did my version over 2 days...

I bet there's some use cases it doesn't handle. On MacIntosh, does it support the D and S keys?

[jgcode]

I bet there's some use cases it doesn't handle. On MacIntosh, does it support the D and S keys?

No seriously as I joked above, it is a hack.

I am not diss'n anybody - I have no doubt that that many man hours were involved to get it right - hence the reason I was asked for a wrapped api.

I know this as the number of use cases that kept coming up was doing my head in.

At the moment it could be nicer but it does the function I want it, I had to block a few things out - like overwriting an existing file so I don't have to handle if in-memory issues etc...

Also I had the issue of having to remove the project items then stick them back in the tree at the top level (I don't like this but can live with it).

So it would be very cool if there was a IN for Library.SaveAll that ran through the dialogs and handled everything.

Do you think this is doable?

Is it worth posting it to the Idea Exchange?

Cheers

-JG

[Aristos Queue]

Do you think this is doable?

Is it worth posting it to the Idea Exchange?

Probably and yes.

[Aristos Queue]

There, fixed that for you

Um, no. I meant what I said.

[hooovahh]

Here is a screenshot of what I did if anyone else is interested

I realize this is 5 years old, but that method won't work for me.  Imagine if you create a new XControl.  When that XControl is made it creates 4 things to go with that library.  There is the Data, Facade, Init, and State.  Through scripting if I make an XControl it will make these 4 items and put them in memory.  I can't perform a save on a member of the library, or the library because of the issue you described.  But I also can't remove these items from the library.  I tried through scripting and I got crashy-crash.  Might have been my fault but after I disconnected the VI from the library then attempted the save of the library it all went bad.

 

So I have private methods on, and I still don't know a way to save a library with unsaved members, that cannot be removed or disconnected from the library.  Any thoughts?

[jgcode]

Nothing from me but I would still love a wrapper for this functionality from NI

[hooovahh]

Okay so I did get a solution for my use case.  One of my new favorite private functions is the Save VI as Buffer.  It performs the same save operation that a VI normally does, but returns the stream of bytes that the file would be, had it been written to disk.  Luckily there is also a Save Library as Buffer.  

 

So using these functions I was able to get the VI and project buffers, then save them to disk using the write binary file.  The only modification I needed was to edit the library buffer stream, modifying the XML to include the relative path to the member.  Since the member hadn't been saved yet the path wasn't stored in the project buffer.  After that I needed to close some references, and it seems to work.

[jgcode]

Okay so I did get a solution for my use case.  One of my new favorite private functions is the Save VI as Buffer.  It performs the same save operation that a VI normally does, but returns the stream of bytes that the file would be, had it been written to disk.  Luckily there is also a Save Library as Buffer.  

 

So using these functions I was able to get the VI and project buffers, then save them to disk using the write binary file.  The only modification I needed was to edit the library buffer stream, modifying the XML to include the relative path to the member.  Since the member hadn't been saved yet the path wasn't stored in the project buffer.  After that I needed to close some references, and it seems to work.

 

Nice. Are you able to post any example code?

Cheers

[hooovahh]

Uh well sorta, I posted an XNode Editor here:

 

https://lavag.org/topic/19069-xnode-editor/

 

And despite the most likes I've gotten on a post (currently 9) it doesn't actually work because of a missing XNode license.  But the code for saving the library, and VI as buffers, then writing them individually does work.

[lordexod]

I don't know which you have a version of labview, but on labview 2014 all works.

LVClass.vi

[hooovahh]

I don't know which you have a version of labview, but on labview 2014 all works.

Yes this works if the members you have in your library already exist on disk.  Here you create the library, but you add members from disk.  In my case I created an XNode which also created an unsaved member for State.  State couldn't be saved because the library hadn't been saved yet, and the library couldn't be saved because State hadn't been saved yet.  As I mentioned earlier this is similar to an XControl where controls and VIs are made simply by creating the XControl.

[candidus]

AQ gave the right instructions but we have to use a private method to set the VI Path.

I stumbled upon that when I tried to script XControls.