LVLIB properties are too hard to get to

[warren_scott]

I'm trying to manage the properties of my LVLIB, and it's annoying....

Normally, for a VI I would open the VI, and then right click the icon and choose VI properties.

Well, LVLIBs don't have an icon in the upper right corner to do that with (they probably should have one -- the default icon template that I configure in the properties -- why should editing the icon template require me to go through some other weird location -- I already know the icon is the upper right corner of the UI).

So since I can't right click the icon and choose VILIB properties, I go to File -> VI Properties.   ##$%$%^#$% That doesn't work either

This doesn't work no matter what is selected in the LVLIB (selecting a VI or the parent LVLIB element, or nothing).

Strike two for doing something I know to find the properties of the LVLIB.

Finally I found you can right click on the parent item of the LVLIB and find a properties selection

So I can get my job done, but why is this so hidden.  It doesn't follow any of the other ways I've learned to find the properties, and to boot the properties window looks totally different between the LVLIB and the VI's

LVLIB:

and for a VI:

So How about this as a suggestion:

1) make the properties screens be similar (I realize they won't have exactly the same options or settings, but having two very different looking UI's for doing the same thing is confusing).  I kinda like the LVLIB one better than the VI one...

2) support File -> properties when you are in a LVLIB to open the properties dialog

3) Since LVLIBs really have Icons (as evidenced by being able to edit their icon template for children) how about having that in the normal location (upper right corner of the UI) we expect from VI's, and being able to click on it and get similar menus.

[smercurio_fc]

I honestly don't understand what you're asking. Why should opening a VI's properties display the properties for a project library? They're two different beasts. One is an object and the other is a container. It never once entered into my mind to go to the VI's File -> Properties menu to get the properties for a project library.

As for your specific points:

(1) If anything, the VI properties window should have the left pane/right pane design, as that's more user-friendly than the dropdown menu. This I would support.

(2) don't agree with this one at all

(3) I don't understand what this is referring to. VI project libraries do not have icons. They're containers, not objects. Just because there's a VI icon template does not mean you can conclude that project libraries have icons.

[warren_scott]

I'm not trying to get the file-> properties in the VI open the properties of the LVLIB, but When you are in the LVLIB, and choose file -> properties in the LVLIB menu (you can't do this right now), you should be able to get to the properties of the LVLIB.  (Just the same as when you choose file -> save in the LVLIB menu system, you save the LVLIB container).  This does mean that the entry in the "File" menu would need to be dynamically changed from "VI Properties" to "LVLIB Properties" or just be "Properties".

The real goal behind #3 is that everyone I have ever seen tries to get to the properties of a VI by right clicking on the icon.  This is how it has always been shown to me at every NI week and local user group too.  If we can put a icon in place for LVLIB's (whether it is 100% correct or not), it would make the user experience for finding the properties of that item much easier.

[Mr.Mike]

@smercurio_fc: I think warren scott was suggesting he should be able to get to the properties from the File menu...the VI Properties menu item is there for VIs, so why isn't it just a general Properties menu item that works for both: when you have a VI open it opens VI properties and when you have a Library open it works for the library (or maybe have two options in that menu -- one for the library and one for the currently selected item)

I agree that the VI properties menu should be updated to be more like the library properties window.

smercurio_fc -- Libraries do have icons.  For standard libraries we treat it as a template for member VIs.  For class libraries (ala LVOOP) it's the icon that shows on the control/indicator/constant.

[smercurio_fc]

---

Mr. Mike said:

smercurio_fc -- Libraries do have icons.  For standard libraries we treat it as a template for member VIs.  For class libraries (ala LVOOP) it's the icon that shows on the control/indicator/constant.

---

I think you and I have a different definition of "icon". Project libraries don't have a front panel -> no icon in the upper right. You can't place a project library "item" on a block diagram -> no icon.

And for a class, you're not specifying the icon of the project library, but rather the icon of the custom control that is the class' private data. How that is defining the icon of the project library I have no idea.

[SteveChandler]

I think the spirit of the idea is simply to get at the properties for the library from the file menu. I don't think that is such a bad idea. I try to avoid the mouse at all costs. I don't know where a lot of things are on the pallettes thanks to quickdrop. I don't even know how to find most of the menu items because I am so acustomed to pressing control and alt key sequences. To access a VIs properties it is CTLR-I. It would be nice to be able to avoid the mouse when accessing properties for a library.

Heh, I avoid the mouse as much as I can but that seems kind of pointless when I am programming with LabVIEW

[smercurio_fc]

Now that I understand the intent of the idea, which is to set the menu item to actually correspond to the item being shown (i.e., VI or project, or project library), then yes, it makes sense for that. I misunderstood the explanation of the problem.

I can't really support the idea with icons since I don't think there's anything to support there, unless you now have icons for projects and project libraries as you do with VIs, but that's a different idea.

[AristosQueue (NI)]

I realize the following is a bit of a tangent, but I can't resist... must be pedantic...

> You can't place a project library "item" on a block diagram -> no icon.

A labview class is a project library and you can drag those project items directly onto a block diagram.

An XControl is a project library. You can put those on a front panel; and if you then create a control reference for that control, you can put that on a block diagram and the icon shows up there.

OK>>>> Back on actual topic...

As a member of LV R&D, I can see that the VI Properites menu item is kind of misleading and might be better to have a Properties item directly for the library when the library is open in its own window.

As a LabVIEW user, I would much rather R&D kill the "library in its own window" so-called feature rather than spend any time enhancing it. I honestly cannot imagine opening an LVLib or any of the other project types in their own window. As far as I'm concerned, you edit libraries from inside the project. End of story. Even having the ability to open libraries in their own windows creates problems when I'm trying to open all the VIs in my project and I select all the project items and choose Open and I get all these damn library windows. Those windows are a hold over from a time when we were worried that the project would be too complicated for users to actually adopt. That is a fear that has not materialized -- anyone using libraries is using the project.

Warren scott, for the record, I don't own that feature, so you don't have to worry about my opinion on this one. 🙂

[warren_scott]

Actually, I (and my team of developers) am actively using libraries and avoiding projects.  The use case of having a bunch of lvlib's around to provide better namespace control and some level of public/private protection is very useful for LabVIEW code that is designed for being called by TestStand, but never actually gets "built" into anything (hence no need to burden ourselves with projects). 

[AristosQueue (NI)]

Burden? Odd phrasing. How do you create a new library without having a project around? Don't you have multiple libraries open simultaneously? If so, doesn't the explosion of windows bother you compared to having a single tree to work from?

[PJM_Labview]

---

@Aristos Queue wrote:

As a LabVIEW user, I would much rather R&D kill the "library in its own window" so-called feature rather than spend any time enhancing it. I honestly cannot imagine opening an LVLib or any of the other project types in their own window. As far as I'm concerned, you edit libraries from inside the project.

---

Please do not do that until major performance improvements are made into the project.

We have several projects with several 1000s of VIs and a lot of classes (lvoop) where we can no longer use the lvproj because doing so result in a very slow IDE (each edit take a lot longer [up to seconds for instance to select an object]) and the only "workaround" is to open each lvoop class file separately (without using the project file).