LabVIEW
Is it just me, or does save all not actually save all?
@tst wrote:
@billko wrote:
@tst wrote:
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.
Things moving into and out of a library are correctly flagged; it's files moving virtually within a library that don't.
The moving I did was within a single library. One test was moving a VI from the main level of the library into a virtual folder and another was moving from one virtual folder to another. Like I said, it's possible that this issue was introduced in a later version or that the repro steps should have more to them.
Also, I didn't check moving items inside a single virtual folder.
@tst wrote:
@billko wrote:
@tst wrote:
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.
Things moving into and out of a library are correctly flagged; it's files moving virtually within a library that don't.
The moving I did was within a single library. One test was moving a VI from the main level of the library into a virtual folder and another was moving from one virtual folder to another. Like I said, it's possible that this issue was introduced in a later version or that the repro steps should have more to them.
Also, I didn't check moving items inside a single virtual folder.
Interesting because I just tried moving a file virtually from the top level of a library into a virtual folder and when I closed the project, the library did not save. If you open the library and make the change, no dirty dot appears and it will close without asking you to save. I have to select save from the file menu of the library for it to record the change. Not even ctrl+s will save it. I feel this is a bug because if you do a diff after saving, you'll see that the xml file shows the file moved to the virtual folder, meaning it is keeping track of the change. It just refuses to believe there is a change unless you force it to by doing an explicit save from the file menu.
@Intaris wrote:
@billko wrote:
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.
No. Lord no.
This is completely the wrong way around. How should the Library reflect this? What if the Library is used in more than one project? Moving the Library in a virtual folder is NOT a real change to the library at all. Only when the Library changes on disk should the Library be aware of anything..
Then we should all use autopopulating folders. No, if the library doesn't want to reflect the way I set it up, then it's not working correctly. Beside, how do you explain that if you explicitly save the library by selecting "Save" from the file menu, it does update? It's a bug.
@Intaris wrote:
Moving the Library in a virtual folder is NOT a real change to the library at all.
We are talking about moving a library member between different virtual folders within the same library.
I could reproduce the issue with LV2020-32bit:
The library can be saved explicitly if you right-click the library > Save > Save.
However neither "Save All (this Library)" nor "Save All (this Project)" actually save the library modification.
With LV2021-32bit, it asks to save the library when closing the project, as expected:
Regards,
Raphaël.
@Intaris wrote:
Ah, that's a big difference. Missed that part. Apologies.
I agree THAT should be saved. That's not a project item at all, that's a Library item. Probably missed that part, I'm catching up on the last 2 weeks after being on vacation.
Yes, class and library information like this just gets lost without any notification from LabVIEW. It has been that way for some time, I forgot it's even a bug, it's just become part of life at this stage. We adapt in order to survive.
I do this all the time. If I remember, I open another window for my replies so I can continue reading. Otherwise I find that my posts frequently become invalid shortly after reading the rest of the topic. And I also just do an explicit save as a matter of workflow. Usually. And when I don't, I am immediately reminded to do so in a not-so-happy way.
I'm glad this got fixed post LV 2020.
@billko wrote:I'm glad this got fixed post LV 2020.
Well, the OP has his issue with LV2024, so a bug may have appeared again in LV2024 Q1.
As I understood, his libraries are marked as modified (because a save prompt appears when closing the project), but the "Save All" functionality does not actually save them, which is a slightly different issue than what I showed with LV2020.
I don't have LV2024, but maybe @_carl can come up with a minimal example project that reproduces the bug and report it to NI...
Tip: doing a gif as I did is quite easy with ScreenToGif application (free).
@raphschru wrote:
@Intaris wrote:
Moving the Library in a virtual folder is NOT a real change to the library at all.We are talking about moving a library member between different virtual folders within the same library.
I could reproduce the issue with LV2020-32bit:
The library can be saved explicitly if you right-click the library > Save > Save.
However neither "Save All (this Library)" nor "Save All (this Project)" actually save the library modification.
With LV2021-32bit, it asks to save the library when closing the project, as expected:
Regards,
Raphaël.
It relates to the context. Since you only changed the lvlib within the context of a single lvproj the lvlib itself does not really accept that change. This one reason why I ALWAYS create a project solely for each specific lvlib development! Other reasons include: adding lvlib documents (Software Requirements, ReadMe.txt files etc...,) Unit Tests, Examples, build specifications, basically everything that the lvlib DEVELOPER needs to deliver the library.
In no case should the lvlib USER (often, other developers integrating the library into specific and diverse projects) be changing ANYTHING in any other context! Frankly, that USER is working "Out of Scope" by attempting to change the library "Where USED" rather than "Where Controlled and documented."
I LIKE that the current behavior causes pain to the developer who forgets to change context!
Plus, the current behavior permits CONCURRENT development of both the lvlib itself and, the using project(s)!
I understand this choice by NI might be considered undesirable by "lone wolf" developers that are not using rigorous software development practices. However, this exact behavior is essential! Just imagine how many times it saves "careless developer of calling project A" from the pain caused when the developers of calling projects B-Zz gang up and give him a good beating for forcing inappropriate changes to those several projects!
I guess a better analogy would be to ask if you would walk into your local public Library a feel comfortable moving the Bible from non-fiction Dewey Decimal 000.xxx to a shelf in Fiction? Would you choose G for God, C for Council of Nicea...? And, how would you reflect that change for every other library with a copy of that work,
