LabVIEW Idea Exchange

Hi,

When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:

Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:

To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):

The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.

Cheers,

Steen

The smaller footprint of the Local Variables in 2010 has increased usability of the IDE and readability of the LabVIEW language. Another node that could benefit from a smaller footprint is the User Event Ref Constant.

Below is some conceptual artwork on what a smaller footprint might look like. Feel free to post more concepts!

Once in a while I complain about font issues in general (here, here, or here), but one of the really weird things are the font sizes as used in LabVIEW.

The font dialog lists them as units of pt, but for some reason they are quite different in size from the same sizes in any other applications (browser, word, etc.). LabVIEW also shows other problems, for example tahoma 14, 15 all look exactly the same... why??

Here is a side-by-side comparison of a wordpad document and a LabVIEW panel. Each line is configured for the indicated font size.

As you can easily see, LabVIEW is the exception. Any other applications I tried agrees with the left panel.

Idea -->LabVIEW should also standardize here!

The title says it all: The property dialog of controls should allow inspecting and changing the default value.

Here's how it could look like.

Sometimes I wand to re-define a default value without actually changing the current value.

current steps

• copy the current value elsewhere
• enter the desired default value
• right-click...data operations...make current value default
• restore the original value (could lose data in case of DBL!)

After implementing the idea

• right-click...properties...enter default value...OK.

Preamble:

Just following up on a sub-idea raised within this recent idea from tst: LabVIEW should break VIs which have hidden code.  I *almost* like tst's idea, but IMO it is a bit too heavy-handed:

• YES, I want better information when there is hidden code on my diagram, but...
• NO, I don't want my code to break!

The Idea:

If a structure hides code beyound it's boundary, then provide a visual indication. For example, the edge of the structure could be coloured red to alert the user that something unexpected is going on.

I use the conditional disable structure in my projects to turn debug options on and off.

At the moment before every build I have to go into the project properties and make sure that DEBUG variable is set to FALSE and after the build I have to change it back.

You can get around this by automating you build but an option in the build specifications would simplify this.

It would make life much more convenient if there were a list of the available (non-system) conditional disable symbols in the application builder dialog where the appropriate variables for the build could be set. This would also allow for a simple duplication of a build spec to have one with DEBUG=TRUE, and one with DEBUG=FALSE.

Oftentimes, rearranging or reordering a Bundle by Name or Unbundle by Name for clusters can yield fewer wire crossings. For instance, below, wire crossings can be eliminated by moving "Timestamp" to the bottom of the Unbundle and "Value" second to bottom on the Bundle:

The current process of moving one of these elements:

1. Increase the size of the node using the Resize Handles on top or bottom, or select "Add Element" from Context Menu (and hope you remember if it adds and element below or above the cell you are clicking on!
2. Wire to the new element, and deal with deleting the old wire
3. Delete the old accessor using either Resize Handles or "Remove Element" from Context Menu

This can be laborious. Instead, I would like a way to quickly reorder the elements. I have a few ideas how this can be accomplished:

1. Context menu with a "Move Up" and "Move Down" action (not so elegant)
2. A pop-up window that allowed rearrangement (think "Rearrange Cases..." on Event Handler or Case Structures)
3. A native drag-and drop on the Unbundle/Bundle node itself. This could be realized given the current "click regions" on the node (hover your mouse and sweep horizontally over one of these nodes... you'll discover the 4 regions). The two "Arrow" regions currently move the node on the BD, but they could be used to rearrange the node (see below)

Just throwing out some ideas, I'm not stuck on any one. So, the idea you are voting for: Provide a User Interface for quickly rearranging elements on a Bundle or Unbundle by Name.

I've been doing a lot of string comparisons lately and I really hate having to drop To Upper/Lower Case function in front of my Equal? comparisons, as shown below:

It would be so much nicer if I could just have a special Case Insensitive mode for the Equal? node (and, it would be nice if the Equal? function changed its visual appearance, somehow, to signify that it is in a Case Insensitive mode):

There seem to me to be a couple of choke points in right-click access to VIs and functions.  One is that I frequently need to use the same VI's repeatedly.  Another is that the quite useful "insert" and "replace" context items only offer a few first-tier options: one or two related palettes, or all palettes.  Try to insert a few datalog functions for example, and you have to navigate down 6 levels for each. It's even worse if you have to use "select a VI..." and browse to it. For the worst cases, insert and replace lose their advantage over copy-paste or quick drop.

 I propose a dynamically generated palette consisting of the last several VIs and functions (even controls) that have been dropped.  This is analogous to recent-commands-list functionalities common in CAD packages.

- As a member of the functions palette, the items in it are at or above the level they are in their normal place in the hierarchy.

- Since it's a palette you could pin it and it would be handy for dropping the same node on two different block diagrams

When wiring a numeric or enum to a case structure, we get the existing case as 1 (or the second enum item) and a default case also containing "0" (or the first enum item). Many times we need a special case only for one item and everything else should be in the default case.

Case structures are happy with just the word "default" in the second case. The unfortunate automatic existence of one other specific selector value in the default case hampers workflow. For example in the vast majority of my coding, I want the special case to be zero and the other case to be the default.

After wiring the selector, I could just enter the desired value in the non-default case that is showing, except if that desired value also exists (for no good obvious reason!) in the default case. If this happens, I need to edit the default case. That should not be necessary.

Suggestion: Whenever a default case is automatically created, it should not contain any extra specific selector values.

Currently text in an "unbundle by name" node is centered. This makes for poor readability when there are several elements being unbundled.

I think that changing the justification from center to left does improve readability.

Note 01: This apply to bundle by name as well.

Note 02: implementing this idea my gave us this one for free.

I started a discussion here

Although the suggestion about using a template is quite nice, I would still like to be able to create a new VI (or sub-VI) from within a project.  I never use the default icon provided by NI.  -- N-E-V-E-R --   That's a personal choice. 

So since I never use that icon, the fact that creating a new VI which auto-generates an icon that is never used, renders that feature useless.  Let's see how many users of LabVIEW also find the default icon useless....  (Kudos would be a way to take a poll).

A nice feature would be to allow the developer to create her / her own default icon.  The default icon is probably somewhere in the ini file (I have not checked).  One of the Options could be to select if the user wants to use their own default, and if so, browse to the icon or have an editor create one.

In my case, when creating a new VI, it ends up with a icon like this:

I would be happy to have a default icon that looks like this:

The idea I am proposing is that developers should be able to have the icon of their choice as a default icon.

And may plenty of kudos adorn this thread..  🙂

I would be surprised if this is not a duplicate but I was unsuccessful finding it.

The subject says it all. Simply add a scrollbar to free text labels. I sometimes use a string constant for free labels simply because they can have a scrollbar.

In the old days the digital display was automatically aligned with the plot legend (if I remember well). Now it is by default not.

It takes some manual alignment actions to get them right. But don't resize your chart!! You can start all over again.

I propose the option to align the digital display as shown in the last picture.

(BTW, looking for duplicates I found one comment in http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Assembly-of-the-graph-s-plots/idc-p/1085440)