LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Make LabVIEW dialogs non-modal.

There have been plenty of times where I'll be doing something inside a LabVIEW editor dialog (like the Properties dialog for a control), but want to quickly look at another block diagram or probe window. I can't, however, because the dialog I'm in is modal, meaning that it won't allow window focus to go anywhere else. So then I have to close the window, go find whatever it was I was looking for, and then re-open the window. Not a huge deal, but it bugs me everytime I do it.

Usually, this happens to me when I'm in a Properties dialog and need to look at a probe from the Probe Watch Window. I'd like to be able to switch to the probe I need without having to close the Properties dialog.

Therefore, I would like dialog windows (including the Icon Editor, which is also modal for some strange reason) to be non-modal. So that we don't forget about them, the windows could still be top-level so that they are always above all of our other windows.

View All (3)

Find and Replace ( Recent Words)

If I have this:

I want to be able to select the objects along the wire, outside of the frame, and then right click inside the frame (or out of it) and move them without a copy-paste-rewire to end up with this:

The key point: I'm not looking for the "wires" to change, but I want the visual structure to change to meet my needs. This is about making the VI better more quickly and with fewer errors and manual inputs.

Note: this is the simplest, most reproducible option. I am dealing with things that are substantially more complex than this.

I have found these "single pane flat sequences" to be amazing for organizing the VI, enhancing readability and utility without hitting performance. I use them to stage for convert to subvi, and moving things in/out of the box is an decent (and manual intensive) part of that.

Ergonomics is also important.

F2 vs. Tools->Edit Text

Better nested cluster navigation

Big clusters... we've all needed to work with them.

Currently, to change from one cluster element in a bundle/unbundle, clicking on the element name brings up context menus with the hierarchical structure of the cluster...from the beginning. Say you want to move to the next element in a cluster at a certain level, you have to navigate all the way through the hierarchy. You could drag down and then rewire and delete, but that's still more effort than feels right.

How about changing the appearance and functionality of (un)bundle by name so that each section of the cluster name is a clickable link. Clicking on it would allow me to browse the hierarchy at that level, so click on the last element (currently Port) would show me the following option:

There's only one option at this level at the moment, but if I were to do the same on the Laser Settings section, it would drop down a menu with All Elements, <redacted section>, Laser Marker Mode and Laser Settings.

View All (4)

I'm very often in this situation:

At some point I realize that I have to change somehow my output indicator, say adding an array dimension, changing an element type, adding a cluster element, whatever.

Well, if I could just right click and choose "Adapt Indicator to wire"....

My current best general workaround is the following:

Go to the wire source (may be far away on the BD) and right-click "Create Indicator"
Select the newly created indicator and double click it to select it on the FP
Ctrl-X cuts the new FP indicator
Select the old indicator on the FP (or go back to BD, double click...)
Ctrl-V replaces the old with the new indicator but leaves it on connector
Go back to the BD and rewire to the proper source/ remove broken wires

If the indicator I wanted to modify was, additionally, Hidden, there are a couple of steps more of Show/Hide... And if instead I invested in cosmetics of the indicator, I have to redo that again from scratch...

View All (3)

Format Variant Probe

View All (3)

Find Callers and unit tests

Right-clicking on a VI in a project and selecting "Find -> Callers" doesn't list any .lvtest files which call the VI in question. I think there should be a relatively easy way to find which unit tests call the VI. I use Find -> Callers when I'm refactoring, and want to know what code might be impacted by a change. It'd be nice to quickly find the unit tests which also call the VI.

Option 1) Have Find -> Callers include .lvtest files in the results alongside calling VIs.

Option 2) Add a separate Find -> Unit Tests

The new Wire Labels in LabVIEW 2010 are fantastic. However, there is one "feature" of the new wire labels which may be irksome in certain circumstances. When you create a SubVI from a selection (Edit > Create SubVI), the terminals in the new SubVI will take on the names of the wire labels, and not the names of the terminals on the root diagram from which the SubVI was named. Here's the scenario, and the option I'd like to see...

This option would give us a choice...

View All (5)

Rename All Matching Class VIs In Hierarchy

There are examples of generic ASCII spreadsheet formats that used fixed-width fields and no delimiter. (see for example the XMAP section of XPLOR files for crystallographic electron density, blue part below).

ZYX
XMAP: section # 0 average density=-0.336 sigma= 0.907
0
-0.97086E+00-0.49927E+00-0.82774E+00-0.13491E+01-0.57034E+00-0.71253E-01
-0.19491E+00 0.61017E+00 0.10064E+01-0.22888E+01-0.94020E+00 0.77451E+00
0.57539E+00-0.31211E-01-0.27430E+00-0.36526E+00 0.34772E+00 0.81884E+00

-0.19954E+01-0.10117E+01 0.18038E+01 0.19008E+01 0.11886E+00-0.41646E+00
0.47560E-01 0.48855E+00 0.57606E+00-0.22320E+00-0.12787E+01 0.47590E+00

...

LabVIEW could easily deal with these sections (i.e. read and write!) using "%12.5e" as format string and an empty string as delimiter. For some reason, an empty string as delimiter does not work for "spreadsheet string to array" and "array to spreadsheet string". If I explicitly wire an empty string to the delimiter input, LabVIEW will silently substutite a tab instead. This is somewhat unexpected, a tab should only be substituted if the input is unwired.

IDEA: An explicit emtpy delimiter string input should be accepted verbatim.

Of course things can go horribly wrong if the field code is variable width, but we need to trust the programmer to be aware and deal with it.

(On a related note, there is still no format code to allow padding the exponent to two digits with zeroes as in the blue parts shown above, however, fortunately the files seem compatible even if I don't edit the exponent to match that pattern)

Message Edited by altenbach on 07-21-2009 12:02 PM

For illustration, create a ring, set the representation to DBL and uncheck "sequential values".

You would think we should be able to enter any value we want on the "edit items" screen, but just try e.g. entering two items with the following two values 3.45e-12 and 8e-7.

The display never switches to E-format and all we later see is 0.00000. The dialog actually throws an error complaining about duplicate values. 😞

Note that the ring itself can work with such values perfectly well but the only way to enter them successfully is by writing to a "strings and values []" property. We can later read them back and they are actually perfectly fine.

Here is an illustration. The edit items is completely useless here. We (1) cannot see the values and (2) we cannot successfully edit them. This is an unecessary limitation.

IDEA: The edit items screen of rings needs full support for the selected datatype.

The way breakpoints are stored (IN the VI!!!) makes working under source control very hard.

In every language I've worked before, breakpoints are items related to the debugging session (thus the debugger), not the source file. Storing breakpoint information in the VI makes it very hard to work under source control (as one is prompted to save a VI, just because a breakpoint was set.) Breakpoints should be stored in some other structure (the project perhaps) or, at least, if the only change to the VI is the breakpoint it should not require the VI to be checked out/saved.

View All (2)

Edit probe names in Probe Watch Window

View All (2)

Hello community,

I would like to introduce the idea of having the selector label being able to break into multiline if the string of selections, handled by this case, is too long for the width of the case / event structure.

I work a lot with enums, either for indicating states or for named indices in arrays. If one case handles some of them and they are not subsequent, the list quick gets quite long, so I have to stretch the block diagram very wide to have them all displayed. Even more obviously this problem is to be seen with event structures, using the the same frame for a lot of events on a number of different controls.

The size of the selector label could increase downwards like the subdiagram label.

What do you think about this?

View All (3)

Short:

Make the VI 'Write Pallete.vi' useable from run-time. As it is now, not being able to use it, prevents implementation of menu automation in built applications (think support applications created for making LabVIEW easier to use).

I hope there isn't a technical reason for it not being useable as it's just creating some text files...

Longer and with background:

I've worked on automating the mnu-file creation. When I was done and had a working solution I started implementing it in our source management applications. Here I found that I could only use the automation from the development environment. (Yes I should have checked that before I started implementing.)

I've used the tool (https://github.com/HenrikDueholm/LV32.2019..AutoMenuCreator) to create menu files for all our tools/packages and it has made it easy to refresh from folder structure when new files are added. However I cannot implement it as an automatic part of our built source management applications so newly committed files could automatically be added to the menu files and auto-linked into the labview folders. Which is what I would very much like to do.

So could you please make 'Write Palette.vi' useable from run-time to make menu automation just that much better? I'm hoping there is a way to do this as it is, as I see it, just generating text files...

Who wouldn't want this to auto update on commits?:

Best regards

Henrik Dueholm

View All (1)

When reopening a project, the position of the window is retained from the last save of the project, the items in the project tree but not the status of the disclosure rectangles. I usually like to have open the "chassis" and FPGA components as well as my top level software folders, and build definitions. I keep sub-vi folder and hardware module folders closed.

It would be a time saver (and relatively simple) to preserve the status of those personal preferences so that reopening a project takes you to the same state you left it in.

Hopefully this is a moderate reward very low effort request.

View All (1)

LabVIEW Idea Exchange

Make LabVIEW dialogs non-modal.

Find and Replace ( Recent Words)

right click - move selected along wire into structure

F2 vs. Tools->Edit Text

Better nested cluster navigation

Right-click: Adapt Output Indicator to its wire

Format Variant Probe

Wait (ms) should accept floating point inputs with "units" of time

Find Callers and unit tests

Wire Labels should be used as terminal names of a new SubVI as an Option, not as Default

Shift + Scroll for horizontal scrolling of front panel and block diagram

Rename All Matching Class VIs In Hierarchy

Allow empty string as spreadsheet delimiter.

"Edit items" screen of rings need to support e-format for the value

Breakpoints should not be stored in VIs

Edit probe names in Probe Watch Window

Add Format Specifier control in "Read Key (Double).vi"

Case Structure / Event Structure Selector Label shows Multiline

Make 'Write Palette.vi' useable from run-time

Retain project tree status of disclosure triangles