LabVIEW Idea Exchange

I'm totally on board with Embedding Labels for Property and Invoke Nodes! Here are some additional improvements to those nodes:

Property Node Concepts

Scripting and Invoke Node Concepts

1. Most importantly, the banner now more closely resembles a Static Control Reference.
2. The directionality arrows are a pixel width's larger - more distinct, and matching the size of the new LV2010 Local Variables.
3. The node banner is the same height as the unlinked property node.
4. Property Nodes and Invoke Nodes are distinguished by the Property Wrench and the Action Arrow glyph.
5. 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!

What's wrong with the current LabVIEW Fonts option dialog? Plenty!

Let's have a look:

• We can only see one of the three font groups
• It does not tell us the name of the current font, just how it looks!

If we specify a custom font, we get a dialog that has confused me since I started out with LabVIEW 4.0 way over 10 years ago.

Especially the two checkboxes in the lower left corner have bugged me since day one, because they are very confusing.

• If we open this dialog from the options menu, both boxes are unchecked.
• If we open this dialog from the BD or FP font pulldown, one of the checkboxes in inoperational, but not greyed out. Why???
• Unless we read the help, it is not clear what they actually do and what they actually show.
• Do I click these to make whatever I have selected the default or do I click these to revert back to the default???
• ...

This font dialog needs to go and be redesigned from scratch!

IDEA:

Why not make the Font options a bit more intuitive. Here's a quick draft. Even if we select the default font, it should show what it is but have the parts on the right greyed out.

It probably would need a small preview area below each selection (not shown). Each can be much smaller than the current preview window. (It does not matter if a 500pt font is clipped a bit.)

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 programming with large applications, often times you'll have clusters carrying a lot of information.  If you hover over the cluster wire and observe Context Help, you might see something like this:

This Context Help window above is rather large and doesn't necessarily make it any easier to see the structure or contents of the cluster. My proposed idea calls for the ability to expand or collapse the cluster contents within the Context Help window, such as this:

What do you think?

I would like to be able to change the z-order of FP Objects programmatically. For starters, I envision the following properties:

1. Layer - Explicitly sets the z-order layer in which an object resides.
2. Promote/Demote - Implicitly sets z-order layer by -1 or +1 (assuming Layer 0 is frontmost)
3. Send to Back/Send to Front - Explicitly sets z-order to the foremost or rearmost layer
4. (Optional) Container property "Layers" - Returns an array of all layer indices currently in use by the container (Page, Panel, Cluster, etc.)
5. (Optional) Container method "Layer.Objects" - Returns array of references to all objects on a layer

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.

I'm developing code, and like most people I know, I have multiple VI's open at once.

If I then go and open the VI properties dialog, I lose track of what VI the properties are for, especially if I get an interruption.  I know I can just close the properties window and open it again for whichever VI I wanted (or go to the parent category to see the name), but this could be solved by simply adding the name of the VI to the window title of the Properties dialog. 

like this:

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:

I'm not sure if this idea already exists, at times i wish to have an option to display the line numbers in a string control/indicator/constant.

NI's response to the ideas thus far appears far too sporadic. For example if you check out the top LabVIEW ideas (http://forums.ni.com/t5/ideas/v2/ideaexchangepage/blog-id/labviewideas/tab/most-kudoed) 7 of the top 10 ideas are still listed as new! Adding insult to injury the average age of these ideas to date is 1,017 days! It is ok to decline ideas but please provide us some indication that this is something you take seriously. It would appear that NI is cherry picking the easiest half dozen or so items from the list so you have a marketing gimmick to list on the LabVIEW release notes. I propose that a threshold is set and made public so that if an idea reaches a certain amount of kudos, R&D must address it, even if that means declining it.

Sometimes you want your front panel fixed to a particular size. Sometimes you also want to access the “Tools,” “Window,” or “Help” menus.

When you have intentionally re-sized your front panel to a specific (small) size, it’s a pain to have to resize the window or switch to a different window every time you want to access something under “Tools” or any of the other menus that are not visible. 

(Sure, I could switch to the block diagram and get to the menus from there. But if I can’t remember the keyboard shortcut to open the block diagram, I have to resize the window to get to the “Window” menu to open the block diagram.)

For example, when you make an XControl, you want to re-size the facade to fit the controls that you put on it. And then you want to keep it at that size. On the built-in Simple Dual-Mode Thermometer example, you can’t see any of the menus past “Edit” on the Facade without re-sizing the XControl.

It would be nice if an arrow or something appeared on the menu bar when the window is sized too small that I could then click on and expand to get to the menus that are not visible.

The Find Items With No Callers dialog box in Project could use a Remove From Project feature. Currenly, we have to use Go To, then remove the VI, then generate a new  Find Items With No Callers list.