"Find" -> "Class Constant" option

[_carl]

I often want to find any cube-dropped class constants for a particular class on block diagrams in my project.  But, to the best of my knowledge, there's no easy way to do this. It'd be great if there was an option to find these when right-clicking on a class in the project:

 

[fefepeto_kb]

I see the value of this idea, but I would like to highlight some things to get polished:

• When searching for a constant only the exact classes constants shall be returned?
• Shall the parent constants be included, as possible placeholders for the class or one of it's siblings, their offspring?
• Shall the child classes be returned too, since they might be handled in a more generic fashion at some point?

Also note that the Find -> Callers returns the constants too, but the noise is very high there, since the controls and other nodes (like bundle and unbundle) might return the class type. And, at least in my experience, that behavior is not very consistent in the light of the above questions. What happened to me multiple times was that the classes returned their parent, but only after the code has been executed. Before that LabVIEW did not connect the two classes, potentially because the project is large.

[wiebe@CARYA]

• Shall the parent constants be included, as possible placeholders for the class or one of it's siblings, their offspring?
• Shall the child classes be returned too, since they might be handled in a more generic fashion at some point?

A child is a parent so, yes, it should find child class constants*.

A parent isn't the child, so no, it should not find parent class constants.**

* Or at least optional. One might be interested in finding only a specific class. Not returning child classes will make life very hard, as you'd have to manually go over all siblings to get all constants.

**If you want to find parent class constant, you can easily search for the parent class's constant. Also, if you include interfaces, there could be more than one parent, but I don't see why you'd be interested in all of them.

I'd like a Search utility for LabVIEW - NI Community that allows all of this. But I am biased 😎.

[Petru_Tarabuta]

+1. This would be very useful. Especially due to the fact that in LabVIEW all classes are ultimately instantiated by a class constant. In other words, searching for a class's constants is often equivalent to searching for the class's constructors, which is obviously useful.

"When searching for a constant only the exact classes constants shall be returned?" - Yes, this would be my preferred behaviour. This would keep things simple and straight-forward.

It would also be great if the right-click menu on a class constant contained a "Find all instances" menu item, like we are used to for subVIs. Selecting that item would produce the same results as when selecting Find >> Constants from the Project Explorer.

[_carl]

• When searching for a constant only the exact classes constants shall be returned? 

---

That would be my preference.  If I was using this, I'd want to find cube-dropped instances of the exact class -- not children or parents.  (Wouldn't be opposed to having additional options for the other options, but it wouldn't be my primary use case.)

[wiebe@CARYA]

If you could only find an exact class, and not it's siblings, the feature would be useless to me most of the time.

I'm not saying it would be useless to be able to do this. That would be useful, and more than we have now. But most often I want to find where I can expect a class's behavior. All siblings inherit this behavior.

(My) classes are often 'virtual', so they shouldn't be instantiated at all. In other languages they can't be instantiated. It would be a waste of time if I had to search each child (recursively).

This would also be a valid case for finding the exact class: you might want to find where the virtual class is instantiated, to hopefully only find it wired to a type case.

[Darren]

There are a few ways this use case could be solved, I'll list all the ones I can think of here, just as a reference, and possibly to drive further discussion:

Project Right-click Option - Basically the feature as requested in this post. This would be implemented as a  new project provider or an addition to an existing project provider, which is a relatively heavy lift in terms of feature work.

New Column in Project > Find Results - I wonder if it would be helpful to show a new column in the Project > Find results that identifies the "type" of item found. SubVI, Control, Indicator, Constant, etc... since those columns are sortable this seems like, in terms of feature work, it might be an easier way to get the information with existing functionality.

Right-Click Plugin - This is essentially what Petru suggested above... right-click on a Class Constant and have an option to find all the other class constants in VIs in memory that match this one. Right-click plugins are relatively easy to implement (see the enthusiasts community here), and don't require changes to LabVIEW components like the previous two options.

VI Analyzer Test - It's relatively easy to write a VI Analyzer test to find specific items. There are many "Find" tests currently available in the Community Tests Library on the VI Analyzer Enthusiasts community. But obviously this solution is non-ideal, as it requires running a separate tool, and is not as useful as being an editor feature like the suggestions above.

[fabric]

---

I love the idea of a new column in the search results window. Maybe post as another idea?

[wiebe@CARYA]

I'm not sure if option 2 solves the problem.

You'd be able to filter on a specific class (type), but not it's derived classes. You'd still have to filter over each individual child recursively, and add the results. This would be tedious. Class names can become very long, for instance if classes live in a library or nested libraries (or PPLs).

1, 3 and 4 could be done by the community. The 3 solutions would be able to share\reuse code.

[avogadro5]

>in LabVIEW all classes are ultimately instantiated by a class constant.

This is not correct. They could come from:

• The type of a control/indicator
• The output of "Get LV Class Default Value" VIs
• Deserialization - values stored in control/indicator defaults and class constants (you can store a descendant class in all of these), XML/binary unflatten nodes
• Probably more I'm not thinking of...

[raphschru]

As @avogadro5 mentioned, a class instance does not always originate from a constant.

So, I would be curious about the actual use case of searching only class constants.

Also, if it is implemented in the same way as "Find All Intances" for SubVIs, it won't search in VIs that are not in memory, making it less useful...