LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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.

The Preferred Execution System setting of a VI allows for more explicit developer control of a VI's thread allocation. Currently there is no way to quickly view which VIs have been configured for which execution system. Furthermore it's not easy to see what execution system a VI configured with 'same as caller' will run under.

This idea is to add an optional color coded representation of each execution system to the VI Hierarchy window. When enabled, each of the execution systems is highlighted with a certain color around VIs, and applied to the lines between VIs.

vi_hierarchy_idea.gif

For VIs with an explicitly configured execution system, the color around the VI would be solid. For VIs set to 'same as caller', the color around the VI would match that of parent in the call chain, but have a different appearance (shaded diagonal colored lines in this example). For VIs which are 'same as caller', but called from multiple different execution systems, the color around the VI would be shaded black.

Full resolution example:

Spoiler

vi_hierarchy_idea.png

Adding this option would allow the developer to quickly view what execution systems have been configured, which ones are not is use, and potential call chains of each execution system.

View All (2)

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

View All (5)

The Tree- Control and the Multicolumn Listbox support the presentation of a Symbols per row. But there are a lot of cases where there is needed more than one symbol per row. One very common scenario is the display of various states (Calculation completed: Checkmark; Results written to file: Checkmark; Assigned Application to open file: App-Icon...). NI does this already in the "Example Finder" window, so it is obvious there is a need for this feature.

I think it is a good practice to hold a pool of symbols, attached to the control, like NI does currently with the Trees and MCLBs. And for performance reasons there could still be the possibility to determine the columns to be capable to display symbols.

So from the LabVIEW programmers point of view there could be added the following properties / methods:

Symbol-Displayable Colums (property, read/write), (1D Array I32): Gets or Sets the indices of colums, which can show symbols and reserve space when the property "Visible Items->Symbols Visible" is set to true
Active Symbol- Column (property, read/write), (I32): Gets or Sets the Column-No which has focus for the next "Item Symbols"-property operation.
Set Column- Symbols (method, takes an I32 as Index for the Column, takes a 1D-Array of I32 as Symbol-pool indices): shortcut for setting the Property "Active Symbol- Column" followed by setting the Property "Item Symbols".
Get Column- Symbols (method, takes an I32 as Index for the Column, returns a 1D-Array of I32 as Symbol-pool indices): shortcut for setting the Property "Active Symbol- Column" followed by reading the Property "Item Symbols".

This should provide compatibility to the current handling of symbols since the property "Symbol-Displayable Colums" defaults to [0], so if "Item Symbols" is read or written to, it is meant to use the first column, which is status quo.

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)

Swap Long

View All (1)

Allow scrolling in a disabled control

View All (5)

Hello all,

This is a rather non-technical request. When classes are created from Project Explorer, a color is assigned by default. If that's a color you're fine with, you hastily modify the icon and move on to more important matters.

While the color assignment works well enough to serve its mundane purpose, I've noticed several weaknesses:

The object "cube" icon is not so easily edited because of its pretty, blurred lines and several colors.
As far as I can tell, there are exactly six color families that LabVIEW assigns to classes: "goldenrod," blue, green, red, yellow, and purple.
Depending on the order you make your classes in, the colors can introduce confusion. e.g. What if three layers of inheritence are all blue? Not a big deal, but confusing nonetheless.

My suggestion is this, and maybe there's a better way to do this:

In the class properties dialog, why not allow the user to simultaneously assign a color scheme to the icon and the class private data ("cube") icon, in one quick step?

This would adjust the hue of the "cube" icon and the VI Icon Template at the same time. It could also optionally modify the wire color accordingly.

Leave everything else on the UI as it is - this would be a new feature in addition to that pre-existing methodogy.

Thank you as always,

Jim

Note: For the sake of simplicity I chose the color picker dialog that LabVIEW uses everywhere else. Any of several other methods could be used, such as a pulldown menu with predefined color names and swatches. (Say, a dozen selections)

Related ideas I came across:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Change-the-color-of-different-classes-in-the-project-explorer/idi-p/1958803

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Class-ICON-update-to-Class-wire-scheme/idi-p/2516440

View All (7)

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.

I would like to remove all broken wires that are currently visible, and not ones hidden in other cases.

I want to be able to select a case, review the broken wires, and mass delete (if applicable). Then select the next case for review.

I never use ctrl-B when working on a large application. I want to review all broken wires before deleting.. but I hate trying to double or triple-click each wire.

Something similar to this post: broken wires ...which notes that it can be accomplished with Quick Drop scripting...

The idea of overloading methods is wide spread in other languages. Labview already supports this in a way with polymorphic vis.

The code snippet below has 2 classes, parent and child

methods are described in the image below.

The underline idea is that parent can define 1 method (poly.vi) that can handle multiple inputs (polymorphic) but does not have to implement the functionality for all the input types (it just needs to know about them) and the child class can override poly.vi and the interface it want to implement.

Even though the code above is correct, Labview gives an error.

"Dynamic dispatch VIs cannot be members of polymorphic VIs."

I dont see why not, since dynamic distpacthing will still have an entry point for both classes (poly.vi) and choosing which polymorphic vi to use will be define at design time.

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)

I suppose this is a grey area between feature and CAR, but it is certainly a long-standing aspect of the LabVIEW editor that vexes me on a daily basis that could be improved.

The issue is that if you are dragging to select objects on the block diagram or front panel and you accidentally move the mouse cursor to the edge of the window, LabVIEW starts scrolling insanely fast in the direction of the mouse. By the time you've figured out what's happening and released the mouse, you're often 4-5 screen lenghts away the actual content of the diagram, and you must now manually scroll back to the main area. To make things worse, you're not really sure where the origin is anymore, so it takes a little blind searching to find the screen contents again. In addition, you're likely left with a selection that is not what you intended, meaning you have to start over (more carefully) from scratch.

I really don't see any reason to scroll the panel so terribly fast. At all. A slow, steady scroll, in my opinion, would always be preferable, since the fast scroll leaves the user no real control at all over what's being selected. If anyone really wants a chaotic super-fast scrolling operation to be preserved, I would perhaps accept a shift-drag option to enable this.

View All (1)

Tables should be indicators by default

Looking at all my body of work, I use tables exclusively as indicators. They are well suited to display formatted results in tabular form, but much less suited for user input, because they only allow strings. If we need to enter numbers, there is no input validation (as we have e.g. for numeric controls), so they are pretty useless for that.

It is thus a bit confusing that the tables in the palettes currently exist as controls. In fact, the modern, classic and system tables are even labeled "Table Control" (seems redundant!), while "Table" alone would have been sufficient (this has already been corrected for the silver controls :)).

It would be much more appropriate if tables are indicators by default. We can always change them to controls in the rare case where this is needed.

I suggest that the various table controls in the palettes be changed to indicators.
Their default name should just be "Table".

Version label on SSP USB keys

Now that the SSP package is delivered on USB instead of DVDs (good stuff!), I have a minor request: Could you have the USB label include a release/version name on its label?

It might add too much of a cost depending on how you get them customized, but if that is not an issue it would be very practical to be able to see what the USB contains by its label (as we could with the DVDs).

On a side note: Many companies have strict regulations on the use of USBs, and the need for such has increased with weaknesses like BadUSB. Perhaps NI could state something about how the USB sticks they send out are protected, either in the delivery package, or just as a statement on ni.com? That way people who need to convince their IT departments to allow them to use the NI USB sticks will have something to show (I'm sure you will have to add some legal disclaimers there as well , but that's OK).

Keep dropped snippet code selected

When dragging a snippet onto the block diagram, its code should remain selected so we can immediately drag (or use the arrow keys to move) it to a better location.

Currently, the new code is not selected and it is nearly impossible to separate it from the existing code, for example if a complicated snippet is dropped on an already complicated block diagram.

(Not everybody has a gigantic screen to resize the existing BD for plenty of whitespace. I also often only have a small strip of the BD showing, with the explorer window containing the "droppee" on top. Dragging the snippet to the BD invariable ends in a complete mess.)

View All (3)

More Colors for Classes

When you create a class, it gets assigned a "random" color. But there are only 6 (or so) colors that are randomly chosen from. I do a lot of LVOOP, and generate a lot of classes. But because there's such a small selection of colors, I'll often drop class methods with the same color banner next to each other (and yes, with text), and it can sometimes be a bit misleading.

Why not have, say, 64 colors that are used to randomly assign class colors? Or better yet, just use a randomly generated color within a range of shades? It's such a simple change yet it would have a meaningful impact on the developer experience (well, at least mine).

_carl_0-1721943387831.png

Variable pixels for Shift+Arrow

Read/Write Enum to TDMS Property

If you attempt to write an Enum to a TDMS Property the function will return error -68007. "This channel or property value contains a data type that is not recognized by this version of LabVIEW." Reading and writing Enums as Channel Data however works just fine.

There are a few work arounds for writing and reading TDMS properties as Enums, attached is one such example where we write the value as a string, then have to convert that back later. There is extra work involved because we need to generate an error if the string value doesn't exist in the enumeration provided.

Example_VI_BD.png

This idea is to ad native Enum Reading/Writing to TDMS properties.

LabVIEW Idea Exchange

Swap Array Elements Primitive

Visualize Preferred Execution System configuration in VI Hierarchy window

A Better "Find Missing Items" and "Find Items with No Callers" in Projects

Multiple Symbols or Icons in a Tree- Control and Multicolumn Listbox

Custom automatic error handling callback

Include the LabVIEW Task Manager in LabVIEW

Swap Long

Allow scrolling in a disabled control

A Better Way to Choose LVOOP Class Colors

Probe Watch Window (Reset Index)

Remove ONLY broken wires in visible cases/sequences/structures

Use Polymorphic VI inside classes as dynamic dispatch to emulate overloading of methods

Allow users to continue working when a build is in progress

Don't scroll so fast on Front Panel and Block Diagram when selecting objects