Where does QD search for diagram objects to list

[nzamora]

I've searched around and cannot find anything even remotely close to what I think I want to know. It was my understanding that bring up QD shows all of your configured shortcuts with the full name of the function in parenthesis followed by a list of just VIs in your palette, and if a project is open, VIs in the project as well. If you go to the config editor you can define a new shortcut to lead to a specified Diagram Shortcut Object. This drop-down appears to be everything that would normally list in QD after your shortcuts.

What I don't understand, is where those diagram shortcut objects are getting populated from. I thought it would be palettes, but the list is too small and clearly does not contain everything in my current palette set. Opening the drop-down, I see that some have a very primitive name: "add" (doesn't even have .vi). Some have basic names: " beep.vi". Some show an owning library after the vi name: "1D Linear Evaluation PtByPt.vi [NI_PtbyPt.lvlib]". Some clearly come from installed packages based on names: "MGI Button Dialog.vi". I even see some that come from a custom palette we have at my company. And lastly, I see some VIs that I personally installed via a VIPM package that I built and installed. But not all of them. And the do not have a library suffix despite being in one.

Ultimately, I think I want to make some packages to install, and I would like those installations to also bring along the ability to QD VIs. And ideally have the library suffix since there are some similarly named VIs. But it seems 50/50 on whether or not a VI from the installed package actually shows up in the possible QD VIs. I'm not sure if I am not installing them in the correct location, or if I'm not just not telling QD about these new VIs to list. 

It seems redundant and an incorrect design pattern to have to say install the VIs I want into the QD plugin folder. Especially since they are not plugins that I want to use. Just VIs to be able to drop or insert.

Any help on figuring out what I'm doing wrong would be appreciated.

I am on LV 2018 32-bit.

[Darren]

If an object is in the palettes, or it is under the My Computer target in your project, it will show up in Quick Drop. Duplicates are removed from the list, so if, for example, you define a "Recursive File List.vi" in your toolkit palette, but LabVIEW already has a "Recursive File List.vi" in its palettes, then only one of them will show up. That's why the library namespacing is important... it's a way to differentiate VIs that have the same name so both will appear in the palettes.

If you are finding that you have a palette object, but it doesn't show up in Quick Drop, please share more specifics of the problem... that shouldn't happen.

[nzamora]

I'm going to have to generalize it since the actual library is for confidential hardware.

I have a library lets call "Module.lvlib". It contains a couple dozen classes. Most of which are data and have some way of instantiating and getting data out. The more uniquely named vis appear when searching, but only show the non-namespaced name. so something like "Check Data IDs Match.vi" shows up. But I have 2 classes with a "To String.vi" method. Only 1 of those appears in search. Despite that it should be namespaced to "Module.lvlib:DataType1.lvclass:To String.vi" and "Module.lvlib:DataType2.lvclass:To String.vi". I would expect both "To String.vi [DataType1.lvclass]" and "To String.vi [DataType2.lvclass]" to appear. Or does QD not care about class namespaces? Because both classes are within the same library, they appear to be the same thing, and are removed for being duplicates?

[Darren]

Ah yes, I have seen this issue before, I even think there's a post on the NI LabVIEW Forum somewhere discussing it. For some reason, the use of class namespaces appears to work sometimes but not others. For example, you can see that there are some classes within libraries that ship as palettes with LabVIEW (Actor Framework, Web Services, and other APIs) and their fully-namespaced VIs appear in Quick Drop without issue. I wasn't ever able to reliably reproduce the issue to share with LabVIEW R&D as a Bug.

If you're able to do so with a sample library + .mnu file, with reliable steps to reproduce, feel free to share those with me and I'll try to get a Bug filed.

As a workaround, you could add Place VI Contents VIs to your palette that have truly unique, non-namespaced names, and those are just wrappers for the individual class VIs that you want to drop. It's messy, but it would work.

Also, in terms of palette organization/design, why do you necessarily need both "To String" VIs in your palette? If it's a dynamic dispatch VI, then couldn't you just put the parent class "To String" in the palette and then whatever child class you wire to it will automatically adapt? I don't see the point in having To String from multiple child classes in the palette.

[nzamora]

Oh I just love when I find edge cases 😞. I'll try to put together a small example after lunch.

The two data classes do not inherit from a common parent because they don't actually have much common data. I don't feel it is worth the extra overhead of another layer of class just to store Name and ID and to get 1 DD vi. Especially when I'm just trying to introduce OO to my colleagues. They are already aprehensive of it.

[Darren]

Gotcha, I wondered if that was the case.

So yeah, the Place VI Contents VI wrappers are going to be the easiest workaround I can think of.