Auto Populating "Current Project" Sub Pallet

[MCKman]

When working on a large project I sometimes want one of my subVIs from some where else within the same project.

I then have to either find it in the long list of VIs in the Project Explorer window (if I remember the exact name) or navigate through my code to find it and drag it into the location I am currently working.

How cool would it be if there were a Current Project subpallet that contained all the VIs being used in the current project (minus the NI VIs).

Something like the view in the pallet of the Find window's Select Object:VIs.

I have heard of users getting something like this by putting their project in the user.lib folder.

mck

[Darren]

Quick Drop will list all VIs/controls/classes in any open projects as items to drop (in addition to all the palette contents, of course).  Available in LabVIEW 2009 and later.

[dthor]

The quick drop has the VIs projects, yes, but many people, including myself, are very visual coders. One of the many reasons why I like labview over text based languages. We like seeing the custom icons that we spend far far too much time on when we're looking for a VI to drop.

Since QD autopopulates from the VI project, I don't think it would be all too difficult to port over to a sub palette. Ideally it would sort by virtual (and actual) project folders, in my opinion.

[Darren]

---

@dthor wrote:

Since QD autopopulates from the VI project, I don't think it would be all too difficult to port over to a sub palette.

---

Unfortunately, the palettes (to my knowledge) do not run any G code as part of their population, whereas Quick Drop is entirely G code.  So yes, I imagine it would be difficult to implement this on the palette side.

[Darin.K]

> but many people, including myself, are very visual coders.

Like dthor I am a visual coder, I was constantly bothered by two "walls of text", Quick Drop and the Palette Search window.  I say was bothered because I have written a new tool dubbed "SpeedDrop" which presents me with icons instead of text.  I can search palette items, selected folders of resuse subVIs and the same project items used by Quick Drop.  Written in a surprisingly short time, so I am sure a truly fast coder on the blue team could do it in short order ( ).  In fact, the hardest part to figure out (palette images) was mostly tricky because I do not have access to inside info.

I would like to share the code at some point, however there are a few things that I am willing to do in my own code, but hesitant in releasing:

1) Private properties/methods

2) Overwriting existing Quick Drop launch

3) .NET methods and scroll wheel support via Windows API (.NET not truly necessary for those on the blue team, most likely)

4) Changes to an installed .lvlib file to allow Getting Started Window with a daemon running in the background.  This RCF behavior bugs me, so I did not want to reproduce it.

5) File dialog supports Snippets and places the code on the cursor, this involves changing palette files.  Probably safe, but I could leave it out.  (It does rock, however).

In short, once you have moved from reading lines of text to visual scanning and pattern matching, there is no going back.  Here is a screen shot:

The icons on the tab show the different search filters, All Items, Palettes, SubVIs, Project Items, Favorites, and Recently dropped.

I may not use this particular idea, but I really like ideas that make LV more graphical and less textual.  (I was going to make up a word that rhymes with 'graphical', but if you figure it out you'll see why I did not use it).

[dthor]

---

@Darren wrote:

palettes (to my knowledge) do not run any G code as part of their population, whereas Quick Drop is entirely G code 

---

Ah, good to know.

Darin.K, that is a really nifty thing you got there. I'm tempted to just take that image and post it as a new idea: replace QD with SD!   If you ever do decide to release it, I'd be very interested in it. I might tweak it and remove some of the items that you mentioned being hesitant about, or I might just see how you did things and try and make one myself.

[David_L]

How about just "Add VI/Function Icons to Quick Drop results"?

[Darren]

I've heard the "I'm a visual coder" line from multiple people who eschew Quick Drop for other LabVIEW editor features. I don't think that's quite the right way to word it, though.  I think any LabVIEW programmer is a "visual coder" by definition. Countless times, I have visualized what the block diagram will look like to solve a particular problem before dropping a single node. Rather, I think the issue here is how we facilitate that visual coding.

Let's start with the palettes. Some people have memorized where things are in the palettes, and they rely on muscle memory to get them there. I was one of these people prior to LabVIEW 8.6.  But, as I've explained many times before, I found this constant navigation of the palettes to be a significant bottleneck to my development.  I had a (visual) idea of what I wanted my diagram to look like, yet I kept having to do this repetitive task to put the diagram together.  Quick Drop's primary purpose...the one that inspired me to write the first prototype in August 2007...is to get objects on the diagram faster. And since I know the names of almost every object I drop on a daily basis, I can get objects on the diagram faster by typing their names. If you don't know the names of the objects you want, then Quick Drop is not for you. If you are browsing for things, you should use the palettes. If you are searching for things, you should use palette search.  If you know the names of things, you should use Quick Drop.  I guess I should point out here that really, I'm not even typing the names of things most of the time...I'm using object name shortcuts for probably 90% of the things I drop.

Nevertheless, I understand that our brains work differently.  Darin.K is clearly a fantastic LabVIEW developer (his Math Node entry in the 2010 coding challenge was far and away my favorite), yet I honestly can't conceive of how SpeedDrop can be useful for getting objects on the diagram faster.  To me, it is a palette of 40 objects that I still have to sift through to find what I want. Yet it seems Quick Drop somehow didn't facilitate faster programming on his part, which is why he wrote his own tool.  But, by virtue of the "scanning" mode your brain must be in when using SpeedDrop, I still contend that Palette Search would be a much better place to put this functionality than Quick Drop.

[Darin.K]

As a rule you never ask the maker of a tool to describe what is good or bad about it.  Suffice to say that I found the palettes and QD sufficiently mismatched to my needs that I wrote my own tool.  The palettes are built in, QD is an easier target.  Due to either an accidental or fiendishly clever choice by Darren, it is not so easy to have something side-by-side with QD (my wild guess is that there is a 'VI activation' event used in conjuction with a string constant as opposed to VI Name property, just a guess).  That is ok, I have rewritten QD from scratch as well.  Having done that, it is clear that QD combined what existed in LV with a few minimally invasive (yet awesome) new methods for placing objects on the cursor.  I went the other way, I envisioned exactly what I wanted and fought LV tooth-and-nail to get as close as possible. 

How do I use SD to get more code on the BD quickly?  Well, first of all, that is rarely my goal.  I use LV for real about 1-2 hours/week so I am no developer.  I play with it a bit more in my free time.  That said, dropping code is not often a rate-limiting step I have a vision, and when I am scanning for it, it is much more intuitive to match its icon than its name.  The brain is not wired to methodically scan lists, it is programmed to search in a semi-random pattern.  The graphical approach just feels right to me.  Here is how I do things faster with SD?

Persistance: SD pops up with the click of the mouse wheel button, remembers the last search (highlighted for immediate type over), and stays up until I dismiss it.  I can often grab several related objects quickly, not one at a time.  Palettes and QD are both a one-at-a-time approach.  I do sometimes pin palettes, but I am not a huge fan.

Coverage of resuse subVIs not in palette:  Strategic vi.lib and my own subVIs are always at my fingertips. Same workflow as for palette items, no need to customize palettes on each machine.

Custom images for controls:  I can view controls by their image (scaled) and not by their name or icon.  Makes it easy to have a large quantity of custom controls.

Mouse Wheel selection:  very quick to move through lists.   Sorry Mac users!

Favorites and Recent Items:  adapts to my current project, and keeps the most used items very accessible.

Quick Browse:  The Browse button is quickly available, and shortcutted.  Snippets are selectable just like a VI.  Snippets are great for reuse code that is Type adaptable.  Drops a bunch of code, wire to the control du jour and you are done.

If nothing else I'll post a video, it took about a microsecond of use to become a convert, perhaps a few seconds of seeing it in action will suffice.

[GregSands]

Darin - please share this somewhere!

[Mark_Yedinak]

My one concern about autopopulating a project palette would be how to filter some of the VIs shown. Many of my projects will have over 1000 VIs total with the multiple classes that get included. I wouldn't want to expose private methods in the palette. I'm not sure if protected should be exposed either. Anyway, a mega palette with a 1000 icons is no easier to navigate that a long text list. While in general I like the concept I'm not sure how easy it would be to implement in a useable and meaningful way.