07-01-2014 09:17 AM
Hi,
did it occur to you that you add a property node (getter/setter of an attribute) in a class, save the project, move the project to another location and open it there, and the property node is missing in the project although the VI file is there in the file system?! Unfortunately it causes other VIs using the property node to be broken after moving the project to the new place.
The class file is kind of XML and I checked it: the proeprty node information is indeed missing, which seems to go lost when saving the project at the original location.
Any idea?
Peter
Solved! Go to Solution.
07-01-2014 10:08 AM
What version of LabVIEW do you use?
I had some problem with property nodes for classes back in version 2010.
07-02-2014 01:47 AM
I'm using LabVIEW 2012 without service pack.
Thanks,
Peter
07-02-2014 04:59 AM
@Bokor wrote:
...save the project, move the project to another location and open it there...
There's your problem. Paths in LV are generally saved as relative paths. When you move the project, it no longer finds the class and the class VIs where it expects to, because it's no longer in the same relative location. If you want to move a project file on disk, do a save as and rename on it, which will correctly update all the relative paths.
I expect that if this happens, then you also see a search dialog where it's looking for files when loading, because those files aren't where it expects it. If you don't set it to find the files, I expect that it's also broken and telling you why (although it's possible that the error message for a missing property VI is not descriptive enough. I haven't checked).
If this doesn't help, upload a concrete example of what you're seeing.
07-02-2014 06:29 AM - edited 07-02-2014 06:36 AM
Well on initial reading I would also have expected the property nodes, being a property of the class (and not the project the class is used in), should also be stored within the class XML file. Is it really true that this information is not stored in the class XML file? It hardly seems possible.
Shane.
07-02-2014 06:33 AM
HI tst,
tst wrote:There's your problem. Paths in LV are generally saved as relative paths. When you move the project, it no longer finds the class and the class VIs where it expects to, because it's no longer in the same relative location. If you want to move a project file on disk, do a save as and rename on it, which will correctly update all the relative paths.
It's exactly thanks to relative paths why projects can be moved without problems. That part is working all right.
@tst wrote:
I expect that if this happens, then you also see a search dialog where it's looking for files when loading, because those files aren't where it expects it. If you don't set it to find the files, I expect that it's also broken and telling you why (although it's possible that the error message for a missing property VI is not descriptive enough. I haven't checked).
The dialog doesn't pop up, I guess, because the property node is not specified in the class file. But the VIs where the property node is used is broken.
tst wrote:
If this doesn't help, upload a concrete example of what you're seeing.
It makes no sense, I'm afraid, because the bug is not visible. You would only see a project with missing property node altough the getter/setter methods are in the project directory.
Peter
07-02-2014 06:35 AM - edited 07-02-2014 06:40 AM
Peter,
if the content regarding the URL of the VI for the property is indeed missing in the lvclass-file, it shouldn't be a relativ/absolute path issue.
So what i want to know for clear:
- PC 1 is used to develop the project including the class (lvclass-file and some VIs). You save the project using the Project Explorer Save All function?
- Then you copy EVERYTHING used in the project manually to PC 2 (a single project directory?).
- Opening the copy on the new machine shows the issue: The lvclass-file does not include the entry for the property node option for getter/setter VIs, but the VIs are in the expected location (within the project folder).
Is this correct?
If so, what does the lvclass-file on PC 1 contain regarding property nodes?
If the setting is there, please compare the original file and the copy by timestamp and size. It seems the lvclass-file is not copied correctly.
If the setting is missing on PC 1, the issue should also occur on the developer machine. When trying to save the lvclass-file: does it overwrite the file and create a new timestamp/size for it?
If not, i would expect the lvclass-file to be write protected......
Norbert
EDIT: We are talking about the yellow marked item type, do we?
07-02-2014 06:47 AM
@Norbert_B wrote:
If the setting is missing on PC 1, the issue should also occur on the developer machine. When trying to save the lvclass-file: does it overwrite the file and create a new timestamp/size for it?
If not, i would expect the lvclass-file to be write protected......
Norbert
Hi Norbert,
it's exactly as you describe. Unfortunately, I cannot reproduce the PC 1 project but I'm sure that I could see the property nodes in the project and that all VIs were clean (not broken).
But your write protocted files hint made me think, as our configuration management stores files protected: the developer on PC 1 gets the sources, adds new property nodes, develops the code, runs the unit tests (all good), and when saving the project he fails to remove the write protection and thinks to save the new lvclass file but in fact he doesn't. Then the property node VIs are checked into the repository, so they're there but not the matching lvclass file.
I want to believe that this is the case and there is no LV bug with saving and storing project changes.
Thanks!
Peter