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.

[warren_scott]

How I create libraries:  File -> New -> Other Files -> Library.  Not any harder than creating a new VI (except that sometimes I need to expand the "other files" tree element, but that's not really hard).  I rarely if ever have multiple libraries open at once.

[AristosQueue (NI)]

warren scott wrote:

> I rarely if ever have multiple libraries open at once.

Ah. And there's the rarity of use case. In apps that use libraries -- both my own apps and those of customers that I've been called in to investigate -- there are generally between 5 or hundreds depending upon the exact nature of the app. Very rarely is there only one.

PJM wrote:

> 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).

I find this weird because those "library only windows" *are* projects -- they are each and every one of them a separate project window, with all the overhead of a project window. Under the hood of LV, they are the same code. So although I believe you when you tell me that the lib-only windows are faster, off the top of my head, I cannot imagine any reason why that would be true.

[tst]

> So although I believe you when you tell me that the lib-only windows are faster, off the top of my head, I cannot imagine any reason why that would be true.

My guess here would be a combination of two factors:

1. Theprojectloadsallthelibrariesandopeningthemseparatelymeansfewerofthemareinmemory (solessRAM).
2. Either calculating the dependencies or iterating through something probably takes time and that's a lot more noticeable when you have a large hierarchy or many items to iterate through.

So it's probably not that the library window is faster, but just that it has less to do.

[PJM_Labview]

> So it's probably not that the library window is faster, but just that it has less to do.

This is my though exactly.

Additionally, when we are in the situation I previously described, we typically close LV and then only open the lvclass(es) that we are working on (and nothing else). Of course this operation load all the class(es) dependencies in memory but this does still provide a normal IDE experience as opposed to having the project file open.