How to do a complete search of all LabVIEW project VIs?

[*3d0g]

---

@Dhubbell wrote:

I'm trying to a similar search.  I know of an exact string that is unique (In this case a table name I call).  I do not remember how/where I created this vi.  It's on my computer, but I can't do a search to find text inside a vi that's not open.

I would like to see something like most common file search programs have . . . "Find Content" and search a folder to find the text content inside any vi that has this text.

I see this request was made nearly a decade ago.  Any luck in Labview to Search Vis in 2021?

---

Any solution yet?

[*3d0g]

---

@Bob_Schor wrote:

My first exposure to LabVIEW was a LabVIEW 7 Real-Time routine to study Sound Localization in human subjects.  This had about 1000 LabVIEW files (VIs and TypeDefs), plus a few VIs with the word "Tree" in their name.  These were simply files that contained subsets of the "real" VIs (and TypeDefs), designed only to bring these files into memory so that LabVIEW's Search could find them.

This seemed silly to me.  After about 4-5 years of LabVIEW experience, and starting my own development (one of the first being a complete re-write of this initial routine), I began to understand the utility of the "Tree" VI and have included them in most of my LabVIEW Projects.  I even designed a VI Template, complete with its own VI Icon, for them --

As with the original LabVIEW 7 "project" (lowercase "p" to distinguish it from the yet-to-be-released LabVIEW Project structure), my larger Projects have a "Woods" of Trees, organized in functional (often hierarchical) units, with no single Tree having more than 150 VIs and TypeDefs included, some of which can, themselves, be Trees.  This works for me -- when I need to "Find All" (from within LabVIEW, which explicitly means "Use LabVIEW to find all "whatever" in memory, loading the Tree brings the "whatever" into memory.

Until something better is available, this works for me.  [Note -- for this to be practical, you really need to have VI Icons for all of your VIs and TypeDefs.  Unfortunately, the only TypeDef whose Icon you can view when the TypeDef is on a Block Diagram is, I believe, the Cluster -- I've had an Idea on the Idea Exchange, perhaps turned down, to extend this to other, maybe even all, TypeDefs, which would make the TypeDef "Tree" much more visually "useful", I believe.]

Bob Schor

---

Do you still say the same, now?  You seem to be saying that you've determined LabVIEW indeed does have a poor search function, even to this day, and that the best solution is create a new vi and drop all the vis of the project into it.  Then search on this newly created vi.  Did I sum it up correctly, or did I get it wrong?

[Bob_Schor]

---

@*3d0g wrote:

---

@Bob_Schor wrote:

[Description of LabVIEW "Tree" function, learned almost two decades ago with LabVIEW 7.]

Bob Schor

---

Do you still say the same, now?  You seem to be saying that you've determined LabVIEW indeed does have a poor search function, even to this day, and that the best solution is create a new vi and drop all the vis of the project into it.  Then search on this newly created vi.  Did I sum it up correctly, or did I get it wrong?

---

LabVIEW has a great search function for VIs and TypeDefs that are loaded into memory during development.  All of my current Projects, during the active Development phase, have one or more of my Tree VIs in the Project, and "opening the Tree" is often the first action I take when opening the Project.  It does "slow me down" a little bit as it forces me to create Icons for all of my VIs (and do other "time-wasting" steps like writing a "Description" for every VI and TypeDef), but it sure speeds up finding things (including bugs!) when dealing with more than a gross of VIs (how gross!).  My "Tree" icon is part of my Icon library.

Bob Schor

[raphschru]

There is currently no better solution than creating a Tree VI as suggested, or a script that loads and traverses each VI in your project.

In every big project I have worked on, I ended up creating a script that can search specific objects or text inside the VIs. This is obviously a painful workaround, but at least you can do pretty much whatever you want, without waiting for NI to improve their tools.

[rolfk]

It also depends on the complexity of your application. I tend to have a top level VI that is basically the main VI of the application (one per target: host, RT, FPGA). Opening that makes usually sure that all relevant VIs are actually in memory. And yes I tend to use static VI references for dynamic VI calls, simply because they include the according independent VI in the VI hierarchy that way. If an application requires a true dynamic hierarchy, I either include the necessary VIs anyhow in a disabled case structure or create a separate tree VI.