LabVIEW Shortcut Menu Plug-Ins
Author: Aristos Queue (NI)
Right-click on a field of a private data control of a class and select "Find All Uses..." to discover all the places where the field is bundled or unbundled. This plug-in will find
- all unnamed Bundle and Unbundle nodes (because those always access all fields)
- any Bundle By Name or Unbundle By Name that references the selected field
- any IPE Unbundle/Bundle pair that references the selected field.
The tool works for dotted fields inside nested clusters.
Before:
After:
For the unnamed (un)bundler you could check if the element is wired?
"Give them a finger, and they’ll take the whole hand" 😊
EDIT: It depends a bit on what you want to know. If you want to know if it's save to delete the item, the unnamed (un)bundlers are relevant. If you want to know where the value is used or set, the element has to be wired.
EDIT 2: I guess it would be useful to have a "Find all reads" and "Find all writes" as well?
Search LabVIEW like a graph! 
I still like this one a lot.
+1 for adding it at installation.
Could the menu be added to the (named) (un)bundlers of class data in a diagram*? As it is it's very useful, but I'm often in the diagram when I want to know if\where the item is also used elsewhere. I now have to locate the class's private data first.
* I know it can, technically, but are there reasons not to do it?
Felipe, I have saved it back to LV18, and it worked without problems.
I did save it back to LV16 for you, only to find I can't attach anything here...
BTW. In the spirit of 'always one more bug'...
There does seem to be a problem with clusters as private data. (Glad I don't have too many of them.)
It seems that access to individual cluster elements are not found.
GOOD: A 'find all uses' on a cluster or it's element returns access to the cluster.
BAD: A 'find all uses' on cluster or it's element does not return access to an individual element.
@wiebe@CARYA wrote:
Thank you Wiebe. Don't bother. I am going to test here using a LV2020 install to save it back. I will let you know.
Apparently this post format is different. I haven't seen a place to attach either, nor reply.
I guess somehow I expected this feature to end up in LabVIEW automatically.
Here's an idea to add it:
For the record, another (tiny corner case) bug...
If the private data item ends with a space (which it probably never should), the (un)bundles aren't found at all.
Apparently, LV does us a favor by removing the space, so the name strings don't match.
Sure was nasty to figure out what was happening, or rather not happening. I hope the fix is just to use a reg.ex. instead of an equal...
I'm working on (testing) my 'pimped' version of this plug-in.
I'm taking the leap because this is pretty much the only plugin I use, and I use it all the time working on, sometimes shocking, inherited code. But even on my own messes it's very useful.
TL;DR Details:
I think (still testing) the following new features will be really useful:
DONE (un)bundlers are identified by element position, to avoid false positives of (un)bundlers with the same name*.
DONE support for nested values (e.g. search for a value in a cluster finding (un)bundling the cluster; search for a cluster, finding items too).
DONE allow searching for a selection of values.
DONE searching (un)bundlers of type def clusters (not just classes!).
DONE starting a search from a type def control(s) or constant(s).
DONE Finding unnamed (un)bundlers (iff wired).
TODO starting a search from one or more (un)bundlers.
TODO presenting (all?) the results. Found items can now match more than 1 searched item...
DONE Tests to allow development without manually using the plug-in
TODO Formal tests (probably Caraya).
This has been a hell of a job... Adding the type def search has a lot of implications. It's been 95% of the work turning this into week(s), not hours, of work.
* Identifying elements uniquely still needs to be done for IPEs, that sadly miss a way the 'index' property that allow getting this info unambiguously. Only names are available, but they don't uniquely identify the element. They also don't account for "." in items, while "." is used as separator... *sigh* I fear I have to use the Wire.Data Offset property, unless someone else has a better idea.
But:
+ Where to put this plugin? (Online I mean, a new site, or here?)
+ The code incl. tests, etc., will (at some point) be in Git (lab or hub). Should the plugin download be there too?
+ Should it add the same menu?
+ Is there a way for this plugin to detect the other one, and adjust it's name? (Pretty sure there's no failsafe way).
I'm a bit torn, because I probably want to keep both plugins for a while, but eventually keep one.
Thanks. I avoided VIPM\packages\etc.. Not my cup of thee (actually prefer coffee).
As a developer, the first time I tried it and lost several days trying, not succeeding, to figure it out. That was an entire toolkit though, palettes etc. and a decade ago.
As a user, I find it only makes thinks more complex. For starters, I now need an account... I also want things in my project, not in vi.lib, but this situation is different.
Would a vipm give the user a choice where to install (all LV versions\per LV version)?
I'll reconsider...
OK, so I'll reconsider VIPM more seriously 😉.
I can simply offer a download of the .llb (or zipped folder named .llb) somewhere on this forum and a VIPM... Thanks for offering to make VIPM happen...
One step at the time though.
- I first have to get it working. Mostly icing the cake atm.
- Then test it a bit more.
- Then put it in an online git.
- Then I can share it...
- Then, in parallel:
- VIPM can be added.
- More tests should be added.
- User documentation...
- Developer documentation...
Of course, there'll be overlap. No need to gold plate a step before proceeding.
Going from 1&2 (the exiting part) to 3 (the boring part) is a big effort...
>VIPM lets you pick which LabVIEW you want to install a package to.
Yes, but plugins can also be installed for all LabVIEW versions, by putting it in "%User%\Documents\LabVIEW Data\PopupMenus\edit time panel and diagram"...
That's where I put the plugins manually... They will be used by all LV versions supporting the code version. That will be 19 and up for this plugin (maps & sets).
