LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

I occasionally hide controls on my FP and control their visibility programmatically during the execution of my program. The problem is that if I edit my UI and the control is hidden, it's very easy not to be aware that it's there and to accidentally overlap it, hide it or even move it off the screen.

 

To solve this, I usually try to save the VIs with all the controls visible, but that's not always feasible.


A better solution - LabVIEW should always show hidden controls in edit mode. It should just have some way of differentiating them from visible controls. This mockup shows them as ghosts, but it can also be any other solution:

 

20779iD19E3A04FFDC0A31

 

In run mode, of course, the control would not be shown. This is similar to the black border you get when objects overlap a tab control.

Hi!

Maybe this has been already requested elsewhere and I'm missing it....

but it would be useful to have a Wait (ms) with connectors for error in and out.

This can help keeping the BD clean...

Marco

18613iCF039EA34765F743

Typical question in development process: "How quickly does my code execute? What runs faster... Code A or Code B?" So, if you're like me, you throw in a quick sequence that looks like this:

 

TimingDuringDevelopment.png

 

AHHH! What a mess! It's so hard to fit it in, with FP real estate so packed these days!

 

We need this:

ProposedTimingDuringDevelopment.png

 Just like my other idea, and for simplicity's sake NI, I would be PERFECTLY happy even if you had to set up the probes during edit mode, and were not able to "probe" while running.

 

 As a bonus, this idea may be extrapolated into n timing probes, where you can find delta t between any two of the probes.

 When you align a control that has increment/decrement buttons to other objects on the front panel that do not have them, LabVIEW aligns the buttons with the edge of the other controls.  The align objects command should ignore the increment decrement buttons and align the border of the control with the borders of the other controls.
 
 align.jpg
 
Workaround:  Hide Inc/Dec Buttons, align objects, Show Inc/Dec buttons.  However not as convenient.

Here's how we currently make cluster element labels appear, and a proposed idea for improvement.

ClusterLabels.png

The problem that height of local variable is 17 pix, and terminal - 16 pix, but distance between terminals in unbundle function is 15 pix.

As result - aligning to vertical compress caused steps in wires:

 

Screenshot.png

 

Right nowterminals/local variables should be slighly overlapped for "step edge free" wiring.

Please synchronize size of these icons with distance between terminals (to 16 pixels - seems to be ideal size)

 

Not sure if it was already in Idea Exchange or not.

 

Andrey.

 

I'd like there to be an option to show some kind of indicator on string controls that you aren't seeing the entire string. This should also apply to string constants on the block diagram.

 

Hidden String.png

I searched for a similar idea, but couldn't find one. Let me know if there is already a similar idea.

Browsing through menus to replace a numeric conversion node is tedious.  How about allowing the selector tool to select from a pull-down menu, just like it does from an unbundle by name node?

 

Existing unbundle node behavior is shown at left.  Desired numeric conversion node behavior is to the right.

 

Quick_changing_of_numeric_comments.png

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:

 

Array_ordinary.png

 

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:

 

Array_loop.png

 

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):

 

Array_more.png

 

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!

 

21658iE20B431D386A4E45

Currently, it's a crapshoot when you drag an ant trail selection box around items on your FP or BD. It's truly an art to become good at selecting objects in LabVIEW - we all learn "hot spots" to place our selection rectangles, and we all heavily rely on the "Shift+Click" method of adding or removing objects from our selection. Below is an example of what actually might be selected when dragging a selection box:

 

SelectionBehaviorCrapshoot.png

 

All horizontal wires were selected down to "ABCDEF", even though just a very small portion of the visible wire was inside the selection box. It's not intuitive to try to not select wire that is hidden behind the Unbundle.

 

I propose a method that mimics selection in some graphics editing and CAD programs: the idea of "Enclosed" and "Inclusive" selections. An Enclosed selection is made by dragging the mouse from L to R. This operation selects only the objects THAT ARE COMPLETELY ENCLOSED by the selection box, ignoring objects that are partially outside the selection (the red arrow is not part of the BD, it merely represents the motion of the cursor):

 

SelectionBehaviorEnclosed.png

 

Alternatively, if you drag your mouse from RIGHT to LEFT for a selection box, you select every single object that is fully or even partially contained within the selection box:

 

SelectionBehaviorInclusive.png

 

Voila! Selection is now a TAUGHT SCIENCE instead of a LEARNED ART!

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!

 

 

 

When you develop with multiple LabVIEW versions, it is sometimes difficult to identify which version you're using or launching based on the icon of the LabVIEW EXE:

 

taskbar.png

 

Here's my Windows 7 taskbar with, among other things, LabVIEW 8.0, 8.5, 8.6, and 2009 icons.  Which one is which?  There are ways to tell, but it sure would be easiest if the version number were overlayed on the icon.  Note the Visual Studio 9.0 icon in the taskbar...I think we should do something very similar with the application icons of future LabVIEW releases.

 

NOTE: The icon should also reflect differences between the 32-bit version of LabVIEW and the 64-bit version of LabVIEW

I think structures should have a better label system. Currently I use free labels of the same color as the loop which looks great and makes the code easy to read and debug. But if I resize my loop I have to manually resize the label as well. I think this should be built into a right-click option.

 

(structure) rick-click » visible items » Structure label

 

Integrated Structure Labels.PNG

I would like the ability to probe the loop iteration terminal ("i" in For and While Loops) without the need to wire it to something (indicator, edge of structure,...).

Currently, the block diagram has an endlessly useful feature. I use it every day - the Distribute Tool.

 

FrontPanelSpacingTool.png 

 

 

The following feature would be AWESOME for expediting BD readability:

 

BlockDiagramSpacingTool.png

The size of the Close Reference VI makes it impossible to draw a proper block diagram.

d.png

 

It is too big!  It does not match with the Property Node vi.

 

Therefore I would propose: --> Make the Close Reference VI smaller!

 

If you are not using the Data Event Terminals in an Event Structure, you might customarily hide them - roll them up so that only one terminal is showing. I would like to hide that remaining terminal. The idea is to not grey-out the Remove Element option when you are down to one terminal. That way, you can remove it. A stub remains to right-click on in order to bring the terminal(s) back if required.

 

24498iD9D667DE43F77BE8  

Currently if you right click on a subVI from the block diagram and choose properties, it brings up the Object Properties dialog.  The only options you can change there are label options, which can easily be changed in the "Visible Items" submenu.  I can't think of one time when this has ever been what I wanted out of this action.  Instead, I think this action should open up the VI Properties Window for the VI.  

 

properties1.png

I don't like the way that long file paths are shown in path controls and indicators:  If the path is longer than the textbox (and it usually is!), the user only sees the first several levels that fit.  This can be pretty confusing.

 

One way to solve this issue is to truncate the path in the middle in such a way that the filename or last folder (which is usually what's most important) is always shown.  I've seen this in other UIs and it should be a natural thing for users to understand.

 

Here's an illustration:

truncate_path_ctrl.png 

 

I think this should be a built in feature of the path controls and indicators, accessible through right-click menus and/or the properties menu of the control at edit time.