LabVIEW Idea Exchange

Quick Drop (Ctrl+Space) should support replacement (Ctrl+P) on the block diagram terminal as well as the front panel icon. The front panel icon can be selected and replaced with another .lvclass but if its block diagram terminal is selected the replace does nothing.

(This is an idea related to Jack's idea here, which however deals with "reshape array".)

When using "built array" with parts that are mismatched in lenght, the largest input wins and the rest are padded with the default value for the given datatype (zero for numerics). This is often not desirable, for example when graphing multiple plots.

Padding with zero causes extra data (zeroes) to show on the graph that did not exist in the original wires. A more desirable option here would be to pad with NaN so only actual data is graphed.

My suggestion is to add an optional input to "built array" that allows defining the pad value is case the inputs are mismatched.

Here is an example how it could look like. (of course the icon would probably need to change a little)

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

This has been discussed in various places like here, but I couldn't find an idea for it...

There are quite a few LabVIEW primitives which will always run, even if presented with an error on the "error in" terminal. Common examples are "Close Reference" and "Close File". 

What would be really useful is to have some kind of visual indication of this behaviour. Ideally this would be a simple marking on the VI icon which could be easily replicated by LV users when we create such VIs ourselves. (It could possibly even be an option in the icon editor!)

Currently the only indication that a VI will run on error is this discrete line in the VI help:

I believe a visual indicator would be much more fitting for LabVIEW as a visual language, and would make this behaviour far more obvious to LabVIEW users.

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.

Currently, you can place a probe on a wire while developing, which is an indicator of the data on a wire. I want the ability to CONTROL the data on the wire, with a data forcing mechanism.

The implementation would be very simple... right click on a wire, and in the context menu the option "Force" would be right under "Probe." It would pop up a window of the forcing control, and while the VI is running and forcing is set to "Enable", the programmer can control the values that pass on the wire. If the force window were set to "Disable", the data in the wire would be completely controlled by the VI's logic.

I think the implementation by NI could be trivially simple. If you only allow a forcing control to be added during edit mode (not while the VI is running), the force could be added as an inline VI (as denoted by the green rectangle on the wire). The code inside the inline VI would be as follows, and the front panel would be "Data Force (1)" as shown above.

Of course, if you could add a force to a wire during runtime like probes, props NI. But I would be PERFECTLY happy if you could only add these force controls in edit mode prior to running.

One level further (and this would be AMAZING, NI, AMAZING): enable and disable certain parts of the cluster that you would like to force and allow the other elements to be controlled by the VI logic. I made the example above because it would be very natural to ONLY force Sensor1 and Sensor2, and letting the output run it's course from your forced input.

Getting a date / time time stamp is not uncommon while developing. This Type def should have a unique icon rather than the default.

I've encountered quite a few limitations when debugging debuggable PPLs, and feel that a number of improvements could be made to this process. I often find myself having to open a second project with the specific dev library in it, and then toggling back and forth between the two which is both confusing and inefficient. This is just scratching the surface, but here are some improvements I'd like to see made:

• Non-editing menu options should remain available. One I use quite commonly: right-click on a class cube, and select "Show Class Library". But it's not available:
  
  The workaround I use is to "Copy Data", press ctrl+n to create a new VI, drop the class cube there, and then right-click on that and select "Show Class Library", then toggle back to the temporary VI and close it.
• VI Properties aren't available in VIs:
  
  I often want to double-check reentrancy settings on VIs to ensure everything's configured correctly.
• Private class data isn't shown. I get why this isn't available in non-debuggable PPLs, and I understand that there's a healthy debate that can be had as to whether or not this should be available in debuggable PPLs. I'm of the opinion that private data should be available in debuggable PPLs as they are meant for debugging, not for distribution.
• Private class methods don't show up in the project.  But if you click on the sub VI for a private method, you can open up the block diagram.  If the block diagram is accessible, it really should show up in the project. I often find myself searching for a VI in the project, and not finding it anywhere, because the method is private.
• Unusual interactions. I've seen a number of scenarios where I'm prompted with requests that I shouldn't be asked.  For instance, if I double-click on a malleable VI in a PPL's block diagram, I get this popup: