Is it just me, or does save all not actually save all?

[billko]

---

@JÞB wrote:

---

Your technical discussion is spot on, but anyone who closes the project only to open it later and find their changes have not taken will tell you that this is a bug.

---

I've hand-edited both project and library files, so I know what's in them.  Maybe you're misunderstanding what I'm getting at.  I know that project explorer is unaware of what goes on inside a library (which is exactly as it should be), but the library should be smart enough to know something has changed and offer to save that change for you, should you exit before saving it.

Again, the technicalities of what you are talking about are spot on, but at the least, LabVIEW has to be smarter about this.

[JÞB]

Mr Ko,

It is like blaming your shopping cart for not saving the grocery list.

Exactly like that!

[tst]

---

@JÞB wrote:

Mr Ko,

It is like blaming your shopping cart for not saving the grocery list.

Exactly like that!

---

@JÞB, I think you are repeatedly misunderstanding the issue.

The scenario is this:

1. You have an open project, which has a library in it.
2. You move items inside the library between virtual folders.
3. The expectation is that the library will be marked as modified and so when you close the project window LV will ask you to save *the library*. People are saying this doesn't happen and I can agree that this would be a bug.

Personally, I don't remember running into something like this, but I don't usually just move items in virtual folders. I also very much try to avoid using Save All* and be very intentional in explicitly saving changes to libraries when I modify them. This can't work 100%, since often some time will pass between making the change and being sure it works and wanting to save it, but I do try to be careful of checking I don't have unsaved changes before I commit my changes. This does usually involve closing the project window so that I can see which things are marked as modified. If the project itself is not marked as modified, I will often create a new VI just so I close the project window and then cancel it so I don't have to reload the project.

* Pretty much the only times I do use Save All is when I try to do a Save As or Save For Previous and my mouse slips and then I'm inevitably annoyed at LV for saving something I didn't want to save and which I now have no way of knowing, unless it happens to be something which is in SCC, so I can see that the file was modified.

[JÞB]

@TST

2 is a bad "move!"

How would the lvproj file need to be saved?

It doesn't,  the shopping cart is not responsible for the items. 

[billko]

---

@JÞB wrote:

@TST

2 is a bad "move!"

How would the lvproj file need to be saved?

It doesn't,  the shopping cart is not responsible for the items. 

---

If the shopping cart was supposed to keep track of where the items were, it damned well better do it right.

[tst]

---

@JÞB wrote:

@TST

2 is a bad "move!"

How would the lvproj file need to be saved?

---

I don't see the problem with step number two. Rearranging items in a library is a perfectly reasonable operation.

No one is expecting the project to need saving after a change to the library. The expectation is for LV to tell you that the library should be saved when you close the project or do a Save All, just like it does with modified VIs and just like it does with libraries for other operations. LV certainly has had the convention for a long time (probably since the beginning) that  modified items are marked as such ("dirty", in NI parlance) and are saved as needed (for instance, when unloading and getting confirmation from the user), so it's a reasonable expectation.

Again, I don't remember running into this issue myself, but since people are describing it, I'll assume it does exist. I mainly posted so that people would consider *NOT* using Save All, as that's my own preference.

As for the cart analogy, the current behavior people are describing is as if you bring a cardboard box with you, put it in the shopping cart, put the items you buy in the box and then just walk out without paying because "the cart only has the box that I brought with me". Obviously, the analogy isn't great (the library is an integral part of the system, unlike the box and in the cart analogy there's no real equivalent to the saving action), but I was trying to go with it.

[JÞB]

Please let me rewrap this.

To me; a lvlib is a nice library of reusable code that has a public API and private members that do the heavy lifting behind the scenes.  Or, it "Abstracts" data handling from the caller.  

A simple example of this is an Action Engine where the private AE Core.vi is placed in Wrapper vis that call each Enumerated Wrapper.vi .

See Ben's famous Action Engine Nugget is always a good read. http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/m-p/503801

Nirvana as a lvlib example.  I have also posted a few examples of how one might restructure an Action Engine as a lvlib. 

Changes to the private Core.vi should never require any caller to require saving!  That's "Abstraction " at its most basic level! The caller says "please do this" the callee doesn't care how what is done as long as what inputs and outputs match terminals and datatype (possibly either dynamically dispatched or malleable)

So, any project that calls into a lvlib only needs to be saved if:

• The lvlib or lvclass Changes data I/O 
• The lvlib or lvclass Changes namespace (name or location on disc)

Otherwise ,  the project (lvproj file) has exactly the same data when opened outside the LabVIEW IDE since it is really an XML formatted Text file that says use this lvlib or lvclass over here on disc!  

[billko]

---

@JÞB wrote:

Please let me rewrap this.

To me; a lvlib is a nice library of reusable code that has a public API and private members that do the heavy lifting behind the scenes.  Or, it "Abstracts" data handling from the caller.  

A simple example of this is an Action Engine where the private AE Core.vi is placed in Wrapper vis that call each Enumerated Wrapper.vi .

See Ben's famous Action Engine Nugget is always a good read. http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/m-p/503801

Nirvana as a lvlib example.  I have also posted a few examples of how one might restructure an Action Engine as a lvlib. 

Changes to the private Core.vi should never require any caller to require saving!  That's "Abstraction " at its most basic level! The caller says "please do this" the callee doesn't care how what is done as long as what inputs and outputs match terminals and datatype (possibly either dynamically dispatched or malleable)

So, any project that calls into a lvlib only needs to be saved if:

• The lvlib or lvclass Changes data I/O 
• The lvlib or lvclass Changes namespace (name or location on disc)

Otherwise ,  the project (lvproj file) has exactly the same data when opened outside the LabVIEW IDE since it is really an XML formatted Text file that says use this lvlib or lvclass over here on disc!  

---

I respond with this:

I still think you are misunderstanding me.  I am not saying the project file should track the changes, but the library file should.  If I move a file virtually within the library, it should track the change and tell me something has changed.  But it doesn't.  It will let you close the library and not tell you, then it will let you close the project and still won't tell you.  (Like you say, there is no reason why the project should care what is going on inside each library, so I can understand why it wouldn't notify you there were unsaved changes in that library.)  The only way you'll know is that the next time you open that library, all your changes will be gone.

I actually think we are in agreement.

[tst]

---

@JÞB wrote:

So, any project that calls into a lvlib only needs to be saved if:

---

Again, like billko just said, the point is to save the library, not the project.

Incidentally, I just tried moving an item between virtual folders in a library and into a virtual folder in another library and when closing the project LV did ask me to save the libraries and correctly identified the change as "Item moved within library", so I'm not sure what the repro steps for this behavior are. That said, this was just a project I happened to have open in LV 2015 and could play with. This issue might have have been introduced in a later version.

[billko]

---

@tst wrote:

---

@JÞB wrote:

So, any project that calls into a lvlib only needs to be saved if:

---

Again, like billko just said, the point is to save the library, not the project.

Incidentally, I just tried moving an item between virtual folders in a library and into a virtual folder in another library and when closing the project LV did ask me to save the libraries and correctly identified the change as "Item moved within library", so I'm not sure what the repro steps for this behavior are. That said, this was just a project I happened to have open in LV 2015 and could play with. This issue might have have been introduced in a later version.

---

Things moving into and out of a library are correctly flagged; it's files moving virtually within a library that don't.