Bookmark Manager Project Dependencies

[Hooovahh]

The new LabVIEW bookmark manager in 2013 is nice but one thing it does not do is scan for bookmarks, inside the dependencies of an open project.  I understand that NI wants to make the loading of bookmarks quick so they likely limited it to not include the dependencies to make the loading faster because it has fewer VIs to scan.  But some times a project will have a majority of the code under the dependencies section.

I think it would be nice if there were an option to load bookmarks under dependencies, but not vi.lib, and user.lib to help keep the number of VIs to scan to a minimum.

Because of the awesome API support for multiple bookmark managers, I have made a new bookmark manager that does as I describe posted here.

[SimonH]

We discussed this and made a conscious decision to not include dependancies that are not explicitly in the project you are working on. Performance was much less of a consideration with regard to dependancies (I believe we are caching bookmarks rather than constantly scanning).

Our reasoning was that any code that you are actively working on would normally be part of a project that you have open. Code that is being used, but not worked on, would be included as a dependancy in the project but not show up in the bookmark manager.  Our goal was to not clutter up your bookmark window with comments you aren't immediately concerned with. For example, imagine you are using someone else's library or framework and you don't want to see their #TODO tags intermingled with yours.

We were also aware that we couldn't predict exactly how everyone would want to use the new feature so we knew early on that we wanted an open API to allow people to do what you have done and create your own to meet your needs  . Thanks for sharing.

If a dominant use case does emerge we're open to changing the default behavior in a future version - I just wanted to give you some of our reasoning.

[Hooovahh]

Thanks for the detailed response.  Understand that I am not asking for any default behavior to be changed, just yet.  I am just one user and I don't know what is a more common use case.  I am asking that there be an exposed option to scan dependencies.  INI, or check box or something would be nice.

A use that was mentioned to me in the demo of the Bookmar Manager, was that a new developer that needed to get up to speed with the code could quickly do that by looking at the bookmarks made.  The primary developer could put bookmarks in places showing where the code does the actual logging, or sampling of data, and anyone unfamiliar with the code can look at the bookmarks and see where the low level calls are being made to do specific functions.  In this example the code that has the bookmarks is more or less complete, and it wouldn't be unreasonable to think that this code would be under the dependencies, because as you put it, "Code that is being used, but not worked on would be included as dependcancy".

If I were to use someone elses library or framework, the majority of the time it will be in the form of a package which would get installed in the user.lib which can be ignored.

[AristosQueue (NI)]

> it wouldn't be unreasonable to think that this code would be under the dependencies,

> because as you put it, "Code that is being used, but not worked on would be

> included as dependcancy".

The thinking was that if you're looking at diagrams at all then you're looking at code under development. If you aren't having to understand how it is implemented because you're just an API user, you should be looking at API documentation, not comments on diagrams. The "getting up to speed" is because someone new is joining the team and is going to be doing bug fixing on that code, not "getting up to speed" as a user of the API.

[fabric]

+1 for an option to include dependencies (excluding vi.lib/user.lib)

[tst]

My project files generally include only top level items, things I want to access quickly or in an organized manner, code which LV added to the project when it was created and I failed to remove, dynamic items and stuff which I don't need, but LV forces me to add to the project (such as an icon for the EXE).

For something like that, a scan of the dependencies (possibly even as a check box in a very accessible place so it can be toggled quickly) would probably be good.

[MGiacomet]

I ONLY include the top-level VI in my projects. People forget to remove the VI's that were being worked on as in the "explanation" above ("Our reasoning was that any code that you are actively working on would normally be part of a project that you have open") and no-longer needed VIs stay in the project forever. The tool does it automatically (load/unload in the dependency list), so let's just it work for us...

NI's "conscious decision to not include dependancies" seems the typical "let's take the easiest path out of the problem", instead of providing a generic solution that works in more than just one use-case.

The excuse "you don't want to see their #TODO tags intermingled with yours" is a matter that can be easily handled by customers's internal processes, i.e., requiring each developer to put their initials in their tags. Wait! That would put yet another requirement on NI, i.e., adding a filtering capability but that would be "no-no" on the easy-out path.

While the API somewhat adds flexibility (and that's nice), NI should act as a tool provider and not throw the problem (lack of a fully developed tool) back to their customers. We primarily use LABView as a tool to create VI's to solve our business problems, not to fix defficiencies in the tool we paid for.