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.
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:
It is not discoverable.
It requires you to remember key combos.
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.
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:
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:
Custom actions should be in the list of Quick Drop items.
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.
There should be a panel which allows customizing options for actions and show the help for regular items.
When your certification expires, do you instantly forget everything you knew? Of course not.
I think the Certifications should be tied to a LabVIEW version. That way, there's an "implied age" to one's Certification (if they haven't taken a newer one), but you are still allowed to produce the Certification on cards, job interviews, etc.
The QControl Toolkit is a fantastic library of tools for developing reusable UI components. I think they are a great alternative to XControls. Not only does the QControl Toolkit provide me the framework for developing my own QControls, but it also ships with some fully functional QControls, my favorite probably being the tree with checkboxes.
I think QControls are useful enough for all LabVIEW users that they should be part of the LabVIEW core product instead of an add-on toolkit.
I would like to be able to create executables that don’t require the runtime engine in LabVIEW. Perhaps a palette of basic functions that can compiled without the runtime engine and an option in the application builder for that. I routinely get executables from programmers that don’t require a runtime installation. I just put it on my desktop and it runs. It would be nice that if I get a request, I could create, build, and send them an exe in an email without worrying about runtime engine versions, transferring large installer files to them, etc.
I'm telling my strudents how they should use the error cluster and how important it is. In subvis no error dialogs should be shown and so on (see topics of LabVIEW Core 1 / Core 2).
But many VIs written by NI have been programmed very sloppy.
Example: VI "Write into spreadsheet file". The error cluster is not wired to the inputs/outputs and if an error occures, an error dialog would pop up. Here is the block diagram of your V "Write into spreadsheet file"I:
Please check all of your VIs and do a revision that we can make well-coded applications where the error handling will work correctly.
Help! I need a way to pack more Classes onto my Block Diagrams!
This idea is simple and quite subtle- reduce the size of the Class Constant on the Block Diagram. The majority of the footprint belongs to the Class Icon, which cannot be sized smaller, but the additional border graphic that creates the "Object Cube" effect can be reduced to give a total footprint of 42x42 pixels down from 48x48 pixels. (If you're counting, that's a 42% reduction in "fluff", discounting the 32x32 that must remain!)
If you're not crazy about the first-draft artwork, feel free to post a new rendition in the Comments section!
This idea came from customer Jason Willis during an NIWeek 2012 brainstorm session with LV developers. To me, it seemed like a good idea, so I figured I would post it to the community to flesh it out and see what kudos it gets.
When you have a reentrant VI, you have the one real VI and many clone VIs. Debugging the clones is hard. One way to make it easier might be to make the probes behave like the breakpoints do.
When you put a breakpoint on an individual clone, only that clone gets the breakpoint. But if you put a breakpoint on the real VI, all the clones get that breakpoint. That gives you a way to stop at a point of execution regardless of which clone gets pulled from the clone pool.
We could make probes do the same: if you put a probe on a real VI, any time the block diagram of a clone gets opened, a probe would be added to its wires in the same locations as on the real VI. If you removed the probe from the real VI, all the duplicate probes on the clones would go away too. But if you added a probe to a clone, the other clones would not get a probe.
The node banner is the same height as the unlinked property node.
Property Nodes and Invoke Nodes are distinguished by the Property Wrench and the Action Arrow glyph.
Scripting properties/methods are now more distinct. Currently, the small node banner inherits a few pixels of light blue distinction if any one property on the property stack IsAScriptingProperty. Proposed, shading will be applied on a per-property basis, allowing better visual distinction and a more coherent choice for what to shade.
Discussions/suggestions/insults/questions encouraged in comments section!
Often, when modifying code, I need to reduce the size of a structure due to removing code. If I have a nested structure system (e.g. event structure in a case statement in a loop), this can get very tedious. It would be nice to have a "shrinkwrap structure" functionality on the right-click menu as a counterpoint to the autogrow. This would be an action that would reduce the structure size to something a bit bigger than the largest contents. An option to set how much extra space to include would be nice.
Whenever you use the KeyFocus property, or simply the tab key on a running VI, whatever control has key focus gets that ugly black border around it. Can we just eliminate this feature, or at the very least, have the ability to disable it? The border doesn't appear on System-style front panel controls, but it does for anything else. I've written all sorts of hacks over the years (the latest being in Quick Drop) where I have to figure out a way to hide that ugly border when a control gets key focus.
In general I would like to see LabVIEW more in line with the OS GUI standards. We have dialog controls and colors, however they are not set up to be the default choice - and we lack other GUI elements like status bars, notify icons, child windows etc. etc. A large part of LV-programmers' time is spent on ways to get LV to mimic what users will recognise and therefor intuitively understand.
In this case I simply miss the "sort glyph" that indicates that a table or listbox is sorted based on a given column and in which direction.
I imagine we could show or hide this and set its direction with a property node...It would not handle the sorting (although that would have been neat as well - if you had an in-built sorting that just needed to know a few parameters about the column data to do the job)...
I sometimes delete controls from the BD and realise some time (from milliseconds to minutes) that I have some broken local variables.
I get greeted by the hugely informative imagery as shown below:
Yeah, good luck realising what exactly you deleted by mistake. No name, no way of finding out what the local PREVIOUSLY linked to.
I suggest retaining at least the name of the Control / Indicator the local was linked to so that the poor programmer (me) has some fighting change of undoing the error. Bear in mind there could be many changes made to a VI before this kind of thing is notices so a simply "undo" fix could end up being VERY awkward indeed.
An example of how this could look:
Here I at least know WHAT I have deleted by mistake.
When entering debug mode (turn execution highlight on) it can be hard to see what is happening.
With event structures it can be hard, but there are subtile changes. Sometimes it's impossible. For instance, if you run this VI, and wait a while, it is impossible to why the VI has not stopped. In this case it's easy to deduce, but it can be really hard. Probes also don't provide a solution here...
SubVI's get a green arrow when they are executing. So, could structures get them as well?
I would like to have an option to export a simplified image of a graph directly into png. The image formats available in LV2010 are bmp, eps, emf and pict. Png is superior to bmp with rougly 100-50 times smaller file sizes. At the moment if I want to export a simplified image of a graph to png then I have to use the extra code below or alternatively export the image to clipboard, paste that into a graphics editor an save it to png. It would be much more simple to have an option to directly export to png. My suggestions below: