LabVIEW Idea Exchange

The situation:

There is a user interface that provides the user with an array control.

The array control provides the user only one or a limited number of elements.

The user must use the scroll bars or the index control to select the correct element that he wants to modify.

The problem:

The user can scroll to a position beyond the last available array element and enter data. This increases the size of the array as expected, but not as desired in the given situation.

After the user finishes entering, the program must check the size of the array and reduce it again.

The proposed solution:

There should be a "max. array index" property of the array control. It should prevent the user from scrolling to a position beyond this maximum element index and/or editing such a position. It should also prevent adding elements via the right-click menu when the maximum number of elements has already been reached.

Extensions:

There could also be a minimum property that prevents the user from deleting array elements so that the total number falls below the minimum.

Notes:
The proposed solution should only affect the user's input capabilities. It should not change the size of the array if it was specified programmatically.

Have you ever placed a background image on your front panel to make it look good, but then found that most of the controls and indicators covered everything up?

Ever wish LabVIEW had more appearance customization to make better looking GUIs?

I would like to propose an opacity slider control in the appearance settings tab of front panel object properties. The added setting would not make the entire objects opacity change; ideally the opacity control would only affect the borders and grey space. With this added control users can make better looking user interfaces without having to make custom controls.

Take a look at the difference:

Not Ideal Front Panel with background image and NO Opacity Control

Beautiful Front Panel with background image that you can still see by setting Opacity Control to 50%

Before and After Appearance Settings tab in the Properties Window for a waveform graph:

Currently the only easy way to implement a similar type of setting is go fully transparent by using the tools palette paintbrush tool and setting the color to transparent:

Kudos and share this idea if you want it to happen!

We have (collectively) complained about coercion dots many times on various LV forums -- they are nearly invisible and there are three different kinds, which require different levels of concern. The problem is that there are very few pixels within a terminal and there's no space for any pattern to differentiate the three kinds of coercion (and changing colors is a problem for reasons discussed here in the Idea Exchange).

Another LV developer had an idea that I liked: add an option to view giant coercion dots. We have avoided this because coercion dots bigger than the terminal would interfere with wiring. However, many developers have a policy of eliminating all coercion dots on their diagrams. For those who have such a policy, they could eliminate the coercion dots as they work, and thus might not see any problem from such large dots. Large dots would solve lots of other usability problems that coercion dots have today.

This option could be something in Tools>>Options, but I'd rather it be something in the View or Edit menus so it can be quickly toggled on or off with a shortcut key.

These graphics are "programmer art" -- I just made the three dots look different. Please sumit alternate images for the three dot types if you have better style suggestions. I did make the three dots differ in both pattern and color so that we avoid problems with colorblindness. The type-only was a solid dot, the widening coercion is a bulls eye, and the narrowing coercion is a single ring. Any redesign should definitely take colorblindess into account.

Problem: When an error occurs inside some DAQmx VIs, the error source (the string component of the error cluster) does not contain the call chain. This means that it is impossible to know the location where the error occurred based on looking at the error message.

Real-world example: The other day I encountered DAQmx error -200477 on a cRIO-9045 that uses DAQmx to acquire data from several different C-Series modules. The real-time application that was running on the cRIO contained an error handling module, which correctly logged the error to file. I saw the following when using PuTTY and the linux 'cat' command to display the contents of the error log file.

Notice that the error message does not contain any information as to where in the codebase this error actually occurred. This meant that I had to spend a few minutes inspecting the moderately large codebase before identifying the likely location of the error. Running subsequent tests I was able to confirm that that was the location of the error. The error was soon understood and fixed.

Root-cause: The root-cause of the issue (lack of call chain information) is the DAQmx Fill In Error Info.vi. In the real-world example above the error was occurring inside the DAQmx Timing (Sample Clock).vi.

The block diagram of this VI is seen below:

Any LabVIEW errors generated inside that VI are generated by the DAQmx Fill In Error Info.vi. This VI is, of course, essentially a simple translator between the return type (I32) output of the Call Library Function Node and a native LabVIEW error. That VI has an unwired input named depth whose default value is 1. This means that only the last link of the call chain is inserted into the error message.

Solution: Always insert the complete call chain inside all DAQmx error messages.

Yup,  Upgrading LabVIEW versions takes a day.

The "Process" today is:

• Install from media
• Configure the new LabVIEW.ini
• install tookits (OpenG, Deploy, VIPM, TSVNtk.....)
• Mass Compile all them......
• Fix palatte views... and import and mass compile User.lib\ for here.....
• Sync glyphs on the icon editor (If the link works......)
• Add VIT's
• Add Project Templates
• Mass compileVIt's and Templates
• fix "Metadata.xml"...

.

.

Yup, about a day of watching paint dry...........mass compiling, ignoring warnings etc......

"MyLabVIEW" would find all of those customizations and import them to the new version!

I've had enough!  Your code does not have to look like this:

Or this:

You don't have to wire a string into Build Path's second input!  It can take a relative path just fine!  This is particularly helpful when building relative paths that involve climbing a directory structure.  But it's also useful for building hard-coded folder paths, or even just specifying a file name:

I've seen code that looks like the first two images way too often, so I propose the following:

• Change the name of the second input of the Build Path function to 'relative path or name'.
• Change the default data type of this input (i.e. what it looks like when unwired) to path instead of string.

The function will still work fine with string inputs (so existing code is fine), but this approach encourages developers to actually use the path data type when working with paths. You should kudo this idea if you have ever (1) written code that looks like the first two images, (2) needed to explain to someone that they can wire a path into Build Path's second input, or (3) gotten burned by multi-platform issues when somebody typed path separators into a string wired into Build Path.