LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bookmark Manager Dependencies

At NI Week a neat new feature that was shown off was the Bookmark Manager.  Now we can leave little #todo tags all over the place and keep track of where we left off before we go on vacation (among other uses).  But during the presentation it was mentioned that VIs in the dependencies were not scanned.  I understand the purpose of the project explorer and structure but many times I will find a project with just a Main.VI and all code needed is in the dependencies.

 

Luckily I also heard that the bookmark manager is extensible and you can make your own, so I did.  Attached is a zip and in it is a new bookmark manager that scanns into depenedencies, but not vi.lib or user.lib by default.  Extract the files into the following folder:

 

<LabVIEW>\resource\dialog\BookmarkManager\managers

 

Now there should be two text files in this folder, Default and Project With Dependencies, along with two folders with the same name.

 

Now when you open the Bookmark Manager from the View menu item you will be prompted to choose the bookmark manager you want to use.  It looks like these settings can be wiped out through editing the LabVIEW.ini file.  It would be nice if one could double click on the bookmark manager they wanted to use but I'm happy with the fact that NI allowed for new managers in the first place.

Message 1 of 13
(7,606 Views)

This is definitely neat! I don't have if you have already, but you could post this in the Idea Exchange to see if it could be implemented in later versions.

dK
0 Kudos
Message 2 of 13
(7,577 Views)

@djDannyK wrote:

This is definitely neat! I don't have if you have already, but you could post this in the Idea Exchange to see if it could be implemented in later versions.


Great idea, I've just made my first idea exchange post here.

Message 3 of 13
(7,571 Views)

A Bookmark Manager with dependencies scanned ...

 

bravo Hooovahh      applaudit.gif    it works fine

 

(kudo)

 

 

0 Kudos
Message 4 of 13
(7,373 Views)

Thank you, Hoovah.

 

I just discovered your post when I came across the same problem.  I've been scattering #TODO all over the place in subVI's to make notes of stuff to handle later.  Later has now come.  I opened up the bookmark manager and only found the ones in my main VI.  Where the heck are the rest?  Well, I only explicitly put subVI's in my project tree if I have a specific reason, otherwise I let the Dependencies folder gather them up.  So I wasn't seeing the subVI's.  Your manager fixes that.

 

It seems like a major oversight for NI not to show bookmarks in subVI's that are certainly loaded into memory.

 

I found one other oddity about the default bookmark manager.  It has a choice for "Main Application Instance".  You'd think it would have everything that exists in that LabVIEW application at that time.  But it comes up with nothing.  Not a single VI, not the particular project, not anything.

0 Kudos
Message 5 of 13
(7,055 Views)

Hooovahh, thank you for this!  Also upvoted your idea exchange post.

0 Kudos
Message 6 of 13
(6,436 Views)

@RavensFan wrote:

Thank you, Hoovah.

 

I just discovered your post when I came across the same problem.  I've been scattering #TODO all over the place in subVI's to make notes of stuff to handle later.  Later has now come.  I opened up the bookmark manager and only found the ones in my main VI.  Where the heck are the rest?  Well, I only explicitly put subVI's in my project tree if I have a specific reason, otherwise I let the Dependencies folder gather them up.  So I wasn't seeing the subVI's.  Your manager fixes that.

 

It seems like a major oversight for NI not to show bookmarks in subVI's that are certainly loaded into memory.

 

I found one other oddity about the default bookmark manager.  It has a choice for "Main Application Instance".  You'd think it would have everything that exists in that LabVIEW application at that time.  But it comes up with nothing.  Not a single VI, not the particular project, not anything.


Curious about what your "specific reasons" are.  I've never really thought about boundaries before.  I guess my boundaries would be "if I made it explicitly for the project, it goes in the project tree".  I don't care to have stuff that specifically go with the project loaded as dependencies.  To me, it seems there would be a lot more potential for cross-linked files and such.  And, as you already noted, files that aren't explicitly in the project tree are harder to keep track of.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 7 of 13
(6,404 Views)

Because I only want to see the particular VI's I care about in the higher level of the tree.  And these would primarily be higher level VI's.  I don't want to see hundreds of lower level subVI's populating the tree (particularly if it is an auto-populating folder which I never use.).  If I cared about something, it would be harder to find in the tree if it is surrounded by other stuff I don't care about.

 

Let the Dependencies gather them up.  If I do want to see if something is in the the structure, then I'll open up dependencies and browse through it.

 

That leads to the 2nd part.  If you explicitly put a VI int he project tree, it is always there, even if you later decide to stop using it.  So it becomes much harder to determine if a particularly subVI is used or unused.  If a VI isn't significant enough for me to explicitly add it in which case I know I'm using it, then I'll know that other VI's are being used when they show up in dependencies.  If they aren't there, then I know I'm not using them.

 

Basically, I don't want to manage large lists of subVI's within the main part of the tree.

Message 8 of 13
(6,385 Views)

@RavensFan wrote:

Because I only want to see the particular VI's I care about in the higher level of the tree.  And these would primarily be higher level VI's.  I don't want to see hundreds of lower level subVI's populating the tree (particularly if it is an auto-populating folder which I never use.).  If I cared about something, it would be harder to find in the tree if it is surrounded by other stuff I don't care about.

 

Let the Dependencies gather them up.  If I do want to see if something is in the the structure, then I'll open up dependencies and browse through it.

 

That leads to the 2nd part.  If you explicitly put a VI int he project tree, it is always there, even if you later decide to stop using it.  So it becomes much harder to determine if a particularly subVI is used or unused.  If a VI isn't significant enough for me to explicitly add it in which case I know I'm using it, then I'll know that other VI's are being used when they show up in dependencies.  If they aren't there, then I know I'm not using them.

 

Basically, I don't want to manage large lists of subVI's within the main part of the tree.


Those are interesting points.  Some of my virtual folders expand to off the bottom of the page; this seems to be one of the issues your method of organization would help.  So you would have the top level VI and maybe the subVIs right under it in the project, but everything else listed as dependencies, or something along those lines?  But if your VI is being called dynamically, it wouldn't show up in your dependencies, but then that might be an exception to the rule, too.

 

I probably won't incorporate your method into my projects, but I can definitely see it making big projects easier to manage.  I'm always looking for new ideas to incorporate into my workflow.  Thanks for sharing!  🙂

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 9 of 13
(6,380 Views)

Correct.

Main VI.  Perhaps a few key subVI's.  Anything dynamically called.  Or perhaps a few other VI's that are main VI's in their own right, but are auxiliary to the project like a VI that perhaps I would use on the side to display a graph, build a config file, or do some extra analysis, but is never really a part of the main application.

 

Also, any files such as libraries that I created, or may have copied from vi.lib but modified to make my own version.

 

No way would I say what I do is what everyone should be doing, but it works for me and my workflow.

 

I find that if I tried to move everything out of dependencies and into the project, I soon lose track of what VI's are truly dependent, or which ones are stale and are no longer used but still exist in the project because I might have used them at one time.

Message 10 of 13
(6,373 Views)