LabVIEW
VIs do not stay in virtual folders...
Try making changes to your VIs and see if they stick. I can't think of anything that would make a project file magically revert.
@billko wrote:
Try making changes to your VIs and see if they stick. I can't think of anything that would make a project file magically revert.
I can change VIs and changes are properly saved.
I've been checking how lvlib's xml structure changes with all manipulations and what I noticed is that my project/library behaves differently depending on which save button/menu I use.
If I use any of Save functions in Project (File -> Save, File -> Save All, File -> Save All (this Project))
the issue occurs and the library is not updated with proper file structure.
If I select Save -> Save directly on my lvlib in my project than the library will be updated...
Surprisingly, if I select Save -> Save All (this Library) directly on my lvlib it will not be updated.
If I do similar thing in the project, but without lvlib, all works fine. I can create and move VIs to virtual folders inside the project.
The fun starts when I use lvlib.
I remember that it worked properly some time ago. I do not know what have changed since then.
So Save All (crtl+shift+s) doesn't save the changes done in the libraries? That's ... interesting.
/Y
@pitol wrote:
@billko wrote:
Try making changes to your VIs and see if they stick. I can't think of anything that would make a project file magically revert.
I can change VIs and changes are properly saved.
I've been checking how lvlib's xml structure changes with all manipulations and what I noticed is that my project/library behaves differently depending on which save button/menu I use.
If I use any of Save functions in Project (File -> Save, File -> Save All, File -> Save All (this Project))
the issue occurs and the library is not updated with proper file structure.
If I select Save -> Save directly on my lvlib in my project than the library will be updated...
Surprisingly, if I select Save -> Save All (this Library) directly on my lvlib it will not be updated.
If I do similar thing in the project, but without lvlib, all works fine. I can create and move VIs to virtual folders inside the project.
The fun starts when I use lvlib.
I remember that it worked properly some time ago. I do not know what have changed since then.
!!!!!! Argh - I forgot all about that. It's burned me once and after that, I actually close the the project (and save) to make sure everything gets updated. "Save all" should "save ALL". Yeeesh... I'm sorry you had to find out the hair-pulling way. 😞
@billko wrote:
!!!!!! Argh - I forgot all about that. It's burned me once and after that, I actually close the the project (and save) to make sure everything gets updated. "Save all" should "save ALL". Yeeesh... I'm sorry you had to find out the hair-pulling way. 😞
Right, If I do not press anything, just close the project and confirm all saves than it works fine.
So is it a bug in LabVIEW or it is just something wrong with my environment?
I don't know if it's a bug or not, but it sure doesn't behave as I would expect it to. It's been like that as long as I can remember.
@billko wrote:
I don't know if it's a bug or not, but it sure doesn't behave as I would expect it to. It's been like that as long as I can remember.
Honestly I can't remember if it worked that way from the beginning.
Additionally, what confuses me the most, some of the guys said it works fine on theirs side...
So I don't know that this is your problem (especially because it sounds like you have a workaround now) but I recently had a project in which this same issue was occuring for some of my VIs in my JKI TestCases (spoiler - the TestCase bit is basically irrelevant).
The difficulty appears to be that there is some maximum "path length" for VIs, including their virtual folders. In my testcases, I usually have several levels of virtual folders (Testing > MyTestCase.lvclass > Tests > MyTestedVIFromSomeOtherClass > ExpectedErrors > testWhenIDoThis_ThatFails_ErrorThrown.vi)
This made the "path length" for want of a better term very long. I don't know if it also includes the actual path, which would account for variation on others' computers (You store the code in C:\Program Files (x86)\My Company With A Long Name\Source Codes\My Project Name\Blah Blah.vi, someone else gets C:\Users\<name>\Downloads\My Project Name\Blah Blah.vi, or similar).
If you have a long path, try shortening some bits and see if that changes the behaviour.
A wild thought; are some file write protected? Do you have the setting 'treat read only VI's as locked'? This would probably not flag VI's as dirty and not trigger 'save all' ...
How does 'separate compiled code' affect behaviour?
/Y
