LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Programmatically update class and library descriptions/icons

Solved!
Go to solution
I'm making (what should have been) a simple project documentation editor that duplicates a specified project tree and allows me to select project items and update the icons and descriptions. I have this working for VIs, .ctls, .vits, etc. but classes and libraries are giving me issues. As soon as you open a reference to a class or library, LabVIEW loads it into memory, which locks it from being edited. So this may be a silly question/rehash of questions asked a hundred times before, but is there a way to either: 1) unlock a class that's in memory (doubt it, and kind of hope not) 2) open a reference to a class in memory with minimal editing permissions (also doubt it) 3) get/set the description and class icons without loading the class into memory aka update properties without opening a reference (sort of doubt it?) 4) solve this problem another way? As far as I can tell, the answer to all of these is 'no' and there is no way to set an existing class or library description/icon programmatically (I know that you can use VI Server to create a class and update the description then, but I'm exclusively talking about classes that already exist on disk). Anyone have any insight?
Nathan Murphy
0 Kudos
Message 1 of 4
(2,318 Views)

When you open the classes manually are they locked?  If so, you probably have some circular dependencies.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 2 of 4
(2,278 Views)
Solution
Accepted by topic author Nathan-M

As you said the class locks, I assume that means you can see it in the Project Explorer. This means the class is already loaded into one editing environment, and classes can only be edited by one environment at a time.

 

Try moving your editor program to a separate project and running it separately. Also, since you say you're duplicating the project tree, make sure you close the first project before trying to edit the second one (assuming your program is duplicating a reference to the class, not duplicating the entire class).

0 Kudos
Message 3 of 4
(2,264 Views)
Thanks to you both - I was trying to put together a small demonstration to show the behavior, but in my simplified demo code everything appears to be working as expected. Time to take a closer look at my actual project and see what I'm doing wrong. Edit: The issue had to do with project dependencies. In the Documentation Editor application I was using a derived class from a parent that was shared with the project I was trying to edit documentation for. I removed the dependency from my documentation editor and now I can work with classes, libraries, etc. Thanks for the help!
Nathan Murphy
0 Kudos
Message 4 of 4
(2,234 Views)