LabVIEW Idea Exchange

tl;dr  There's a summary at the bottom if this is too long for you.

Quick Drop is pretty useful when it comes to dropping things and the fact that it also gets items from the project is great.

What I don't like about QD, however, is the keyboard shortcuts. These allow you to perform custom actions in LV and the concept itself is great, but the implementation QD uses has some issues which other similar tools like the right-click framework and LabVIEW Speak don't have, such as the items in the following list.

The problems:

• It requires you to remember keyboard combos to call the plugins. That's great as a secondary access mechanism, but is terrible as a main one for a few reasons:
1. It is not discoverable.
2. It requires you to remember key combos.
3. It doesn't work if you want a longer list of macros which perform all kinds of useful operations, because you run out of available shortcuts.
4. Likewise, you have shortcut collisions, because people want to use the same shortcut for different plugins, so you might say "Ctrl+T", and it will mean something else to the person you're talking to.
• Setting options on the plugins is done by pressing the Shift key or other similar magic combos instead of having a clear representation in the user interface.

So, what can we do about it?

I think a good first step would be to stop thinking of these as "keyboard shortcuts". They should be thought of as custom actions or macros and they should simply appear in the list
along with the regular items, like so:

There are a few things to point out in this image:

• The actions appear in the list using their full names and they have a glyph to set them apart from the other items.
• The actions may (or may not) have a shortcut.
• The actions may (or may not) have a keyboard shortcut (and there's no reason in principle why regular items can't have them too). This solves the existing problem of the shortcut limit - you only assign shortcuts to actions you access regularly, just like you can already do today with menu items.
• There's a ring on the bottom which shows just the items, just the actions, or both. Ideally, the value of this ring would also be settable by other means (e.g. open QD using Ctrl+Shift+Space and the list only shows the actions or open QD when you have a selection and the list only shows the actions).

OK, so that's step one and it solves the first issue - the actions are discoverable, accessible and not limited in number.

Now step two - some of you may have noticed that the image has another new thing - there's an expand button on the right side.
Clicking that button will open this panel:

This area shows the details of the currently selected action and allows selecting options for it.

Here's what we see in this example:

• A title.
• A description.
• An image.
• In the settings area, I gave the "Build array of references" action an option - you can choose to align the Build Array node to the center, the top or the bottom of the references.

The panel should remember its last open setting between calls and when it's open, it should work asynchronously, so that it doesn't delay the operation of QD.
For the VIs which appear in the panel, there should be a standard template for loading and saving values, for showing titles and help data and for shutting down. If the VI fails to respond to the shutdown command within N ms, Quick Drop should proceed and not wait for it.

Of course, once we have this panel, the next logical step is to also have it show the help for standard items, similar to this idea:

So, to sum up:

1. Custom actions should be in the list of Quick Drop items.
2. Shortcuts for actions and items should be fully customizable. That means that you can still use keyboard shortcuts to call the actions, just like today.
   
3. There should be a panel which allows customizing options for actions and show the help for regular items.

I am struggling with my Event Structure event list and the corresponding list of cases in the parallel consumer loop Case Structure.

Both have currently over 100 cases each and finding one or scrolling down to access the latest one has become painful due to the lack of a scrollbar in these lists.

For instance, here is the Event Structure list:

Same goes for the list of controls in a Local Variable (and other objects, I am sure).

There is no reason why such lists do not have a vertical scrollbar when that corresponding to a Enum do have a scrollbar:

Or is there?

Suggestion: All long pulldown lists should have a vertical scrollbar

So when it comes to using a queue, there is a somewhat common design pattern used by NI examples, which makes a producer consumer loop, where the consumer uses a dequeue function with a timeout of -1.  This means the function will wait forever until an event comes in.  But a neat feature of this function is it also returns when the queue reference becomes invalid, which can happen if the queue reference is closed, or if the VI that created that reference stops running.

This idea is to have similar functionality when it comes to user events.  I have a common design pattern with a publisher subscriber design where a user event is created and multiple loops register for it.  If for some reason the main VI stops, that reference becomes invalid but my other asynchronous loops will continue running.  In the past I've added a timeout case, where I check to see if the user event is still valid once every 5 seconds or so, and if it isn't then I go through my shutdown process.

What I am thinking is that there could be another event to register for, which gets generated when that user event which is registered for, becomes invalid so that polling for the validity of the user event isn't necessary.

before:

after: