Bookmark Manager Dependencies

[Hooovahh]

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.

[[dk]]

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.

[Hooovahh]

---

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

[ouadji]

A Bookmark Manager with dependencies scanned ...

bravo Hooovahh          it works fine

(kudo)

[RavensFan]

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.

[dougm]

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

[billko]

---

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

[RavensFan]

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.

[billko]

---

@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!  🙂

[RavensFan]

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.