LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

I often have code in my apps where some error-out nodes are not wired, simply because the errors are generally not of interest to me or the error wiring would clutter up my block diagram. Typically this happens a lot in UI handling code where a lot of property nodes are used. For these parts I would rely on the automatic error handling for debugging purposes. One of the drawbacks of this method is that program execution is suspended when the automatic error handler kicks in. Even worse if this happens for code that is in a loop. You're only option then would be to abort the app, which e.g. is no good for your reference-based objects, etc.

I would love to have the ability to just specify my own 'Automatic Error Handler', enabling me to decide what to do with the unhandled errors. Just logging them is what first comes to mind, but maybe also do some special stuff depending on the type of error, just like a 'normal' error handler. I want to be in control!

Added values of this is that your application then has a catch-all error handler which enables you to at least log every error that occurs, even if not wired through. (Everyone forgets to wire some error-out that they actually did want to wire one time or another don't they? ;-))

Ofcourse the proposed setting in the image would ideally also be available programmatically by application property nodes.

View All (3)

It would be nice to add another dimension to the system exec.vi that gives the user the option to open up the “Run as Administrator” command prompt in Windows 7. This would enable a system administrator to use LabVIEW to make certain, currently restricted, changes to the computer. I don’t believe it would create a security risk because you have to be logged in as an administrator anyway to have the access rights

As far as I’ve seen, there really is no string that you can enter into the command line that will instruct an elevated command prompt to open. With this added functionality in the system exec vi, however, you will be given more flexibility with what you can do through your LabVIEW program.

View All (3)

Allow scrolling in a disabled control

View All (5)

Under Web Services there is a conversion palette. One of the functions here is to convert LV Image data to a PNG stream. This is super useful when dealing with sending and receiving large amounts of PNG data over something like websockets. I've used this in places where a web page can control a VI, and the image of some front panel controls can be sent to the web page.

However only recently did I realize this function turns the image into a PNG stream that is completely uncompressed. This idea is to expose the Compression input to the VI. Here is just one example where I get the image of a control then represent it as a PNG. With no compression this file is over 64KB. With just the most minimum compression that drops to 3KB, and down to 2KB under the highest compression.

When you right-click on a connector pane terminal, a context menu pops up -- but there isn't a good indication of which terminal you've clicked on:

You could assume that selected terminal is at the top-left corner of the context menu, but (due to a bug, I'm assuming), the actually selected terminal is a few pixels down and to the right of where you clicked.

What if the terminal you right-clicked on got highlighted while the context menu was shown? This would provide visual feedback of the selected terminal, giving you confidence that you clicked on the terminal you thought you clicked on (and avoid mistakes of configuring the wrong terminal). I can't even begin to count the number of times I've set the wrong terminal to "recommended" or disconnected a different terminal than expected. Could look something like this:

(which just piggy-backs on the appearance when you're wiring up a terminal:

)

Bonus points if the bug gets addressed where clicks are actually a few pixels off.

Currently, "build path" function has input "base path" set as recommended. This can cause issue when you accidentally do not wire this input. By default there is empty path, which is not really helpful and even if there was any case when you want to wire empty path to build path function, you can easily create constant. Therefore, it would be much more user friendly to have "base path" input of "build path" function set as required by default.

Swap Array Elements Primitive

Is it immediately obvious to you what the following code does?

This rats nest simply swaps two elements in an array, a very common operation when trying to operate on a large array in-place. The In Place Element Structure helps the looks a little, but I find the performance to lag when used in a tight loop, you know, the kind you encounter when you are trying to operate on large arrays.

I would like a simple primitive (sorry too lazy for a picture) which simply swaps two elements in an array. It should be similar to the Replace Array Subset function, except for two sets of index inputs and no subset input. If you want to really make my day be sure to allow disabled inputs to swap rows and columns in one shot for 2D arrays, or pages or volumes or whatever in higher dimensional arrays.

Situation:

You want to show a coworker or customer something "real quick" in the LabVIEW. So you open a new VI, open the block diagram, and open the quick drop accidentally because you thought the palettes were already loaded.

DANGIT you forgot that you haven't accessed the palettes since you started LabVIEW. Now you have to resort to awkward conversation defending LabVIEW about how awesome it is, even though it can sometimes be slow, etc, etc. If you decide to skip the awkward conversation and instead try clicking out of the window you see this awful image:

Oh No! Did LabVIEW crash? Is it broken? How long will this take?

Solution:

Cancel button on the windows in question that allows you to stop loading the palettes (or switch it to loading in the background) so that you can go back to work and find your function the old fashion way. Save you time. Save you annoyance. Save LabVIEW some street cred.

The world is a happier place...

View All (4)

View All (8)

When a build is in progress (Application Developer or FPGA*), the entire LabVIEW IDE is blocked.

Since some builds can take a long time, it would be far more productive if users could continue working in parallel with the build. Example use cases:

Initiate a build for an RT target, then work on code for the PC server
Initiate a build for one project, then work on code for another project

To prevent accidents, LabVIEW could reserve all the VIs/libraries that are part of the Build Specification:

The call tree of "Startup VIs"
The "Always Included" VIs).

*At least the FPGA build only blocks at the preparation stage, but that takes a while too.

View All (2)

Although I expect that it will take a while before this is implemented I would like to add the request so NI can start thinking about it.

As you might have noticed that Microsoft announced a few things on Microsoft build 2015.

Aside from the hololens and windows 10 for the raspberry pi they both share 1 common factor. They both run "Universal apps" (see http://www.engadget.com/2015/01/21/windows-10-makes-microsofts-dream-of-universal-apps-come-true ).

So it would be great if we can run LabVIEW programs as a "universal app" and run our code on all windows 10 devices..

Probe Watch Window (Reset Index)

Reset the Probe index when the <Probe Watch Window" is closed

above, the probe index equal 18, however only one probe is active.

When you close the <Probe Watch Window> ...therefore when you close all probes,

in this case, reset the probe index for the next time.

It's useless and annoying to have a probe index equal to 18 (sometimes much more),

when only one probe is active. Thank you.

Currently: When you "Find Missing Items" in a project, it thinks a few seconds (on a large project) and pops up a non-resizable window. You can double click on an item in the list, which closes the Missing Items list and it highlights the missing item in the project. You remove that item (or relink it) in the project, and then have to "Find Missing Items" again. Wait a few seconds, rinse, repeat...

Proposed:

1. When you double click on an item in the Missing Items list, do not close the list - leave it open, and gray out items that have been taken care of and are no longer "missing" (like the find dialog, when you delete a found item).

2. Allow the columns to be sorted by clicking on the header Name, Location in Project, or Path (this one holds a dear place in my heart)

3. Finally, allow the window to be resizable (a common request...).

(I have given the example for "Find Missing Items"... you can apply the same concepts to "Find Items with No Callers")

Message Edited by mechelecengr on 08-26-2009 02:19 PM