LabVIEW Idea Exchange

Hello,

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.

Regards

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?

The idea is simple: if the label ends in a number (i.e. consecutive string of numeric characters), increment that number:

It seems like it only works if there is a space character. If there is a good reason for doing it that way, help me understand what it is.

I linked some similar ideas below. I like these discussions for the most part, but they tend to have broader scopes than what I'm suggesting.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-er-automatic-label-names-on-copy/idi-p/1873663

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Auto-increment-number-in-middle-of-control-name/idi-p/977710

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Don-t-skip-quot-1-quot-during-automatic-naming-of-copies/idi-p/977300#A2089

Is LabVIEW available for Android based systems and other touch interface systems.If not how about using LabVIEW for mobile measurements using these systems.

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!

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.

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.)

Check out this nice readable diagram:

Whoa there pardner, not so fast. The control reference labeled "Numeric 1" is actually linked to the "Numeric 3" control. And the property node labeled "Numeric 2" is actually linked to the "Numeric 1" control. Etc., etc.

I see no reason to change the labels of Control References and Implicit Property/Invoke Nodes. If you need to document them beyond their label, attach a free label to them. We don't allow changing the labels of subVIs, so the precedent has been set. For the sake of diagram readability, we shouldn't allow changing labels of these objects either.