LabVIEW Idea Exchange

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

Once in a while I encounter a case or event list that forces me to grow the structure

- in order to keep the list readable:

Selector.png

It would be nice if the item-list would automatically "wrap" instead.  

Selector4.png

(Inspired by this discussion)

 

The Index & Bundle Cluster Array function currently discards any labels of the input data. I think it would be more useful if it would try to retain the names (i.e. copy the original array labels (if available) to the element labels of the output).

 

The picture illustrates the idea. On the left we see the current behavior and on the right what we would get after this idea is implemented.

 

Error wires can be passed into most boolean logic in LabVIEW.

 

Except...they can't be passed directly in as the condition for conditional tunnels:

_carl_0-1729004322300.png

For consistency, this should be allowed.

 

Digital display Misalignment.png

Digital display Misalignment solution.png

 

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)

 

Probing a typedef results in a vertical list showing all the fields in the cluster.  Creating the typedef cluster often involves organizing the fields in a particular layout, setting units etc.  It seems like probing the data and displaying it in the same format makes more sense.

 

For instance, I have a cluster of camera information set up as a strict typedef:

 

STSLabs_0-1653830762726.png

 

When I probe a wire of this information I get:

 

STSLabs_1-1653830848197.png

 

This cluster isn't too big so getting to all the information doesn't require a lot of searching and scrolling, but that can be an issue.  What's more of a pain is that the default unit for angles is rad and I cannot mentally convert them quickly so I end up having to double-click each 'rad' label in the probe window and change them to 'deg' so I can confirm the data is what I expect.

 

I know I can create a custom probe to display the typedef, but having to constantly create custom probes for each cluster is a bit of a burden.

 

Am I missing something?  Is there a good reason to NOT display the probe using the typedef?

In Windows File Explorer, Alt + double-click on a file or folder pops up that item's Properties page. It is equivalent to right-clicking and selecting Properties. This is a useful, time-saving keyboard shortcut/gesture.

 

The same keyboard shortcut/gesture should work in the Project Explorer. Executing the shortcut would pop up the Properties window of whichever item was double-clicked on.

 

The shortcut should work for lvclass and lvlib items, VIs, and CTLs (and possibly other item types too). For lvclass and lvlib items the Properties window would appear. For VIs and CTLs the VI Properties window would appear (equivalent to Ctrl + I).

 

Screenshot 1

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Screenshot 2

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Thanks

If you have an event that contains a cluster typedef, then the event structure automatically unbundles the data:_carl_0-1633037893996.png

I generally want to work with the entire typdef though. Why not expose the entire typdef to improve code maintainability?

 

(No one wants to re-bundle that data just to send it to a subVI or new event...and then risk losing data when a new property is added later.  Workarounds include adding a typdef of a typdef, or going class-based...but that overhead/creativity shouldn't be necessary.)

 

When selecting a set of object that are from the same class, I'd like to be able to change some of their main properties at once from the right click menu.

For instance, when selecting a bunch of numeric controls, being able to change all their representation to U8 without having to open the property page (which sometimes take some time to load.

This could be done either via the r.click option, or even via the properties page that would show that it is for more than 1 item. Via the property page 

VinnyAstro_0-1705567415946.png

 

From the property page, it would be nice to have the possibility to easily change their label and caption independently and faster (using tab) than to have to change them manually by double clinking on the labels, hoping to not click on the side of the box.

 

This happens to me all the time:

VinnyAstro_1-1705568287315.png

This could be a viable option in my opinion (Please excuse my poor designer capabilities):

VinnyAstro_2-1705569130610.pngVinnyAstro_4-1705569195313.png

 

 

 - Vincent.

When I Control+Right click and drag to expand a block diagram. The expansion should NOT effect all of the unseen case frames

 

I am really tired of stuff like this happening when I expand the diagram of another frame of the same case horizontally and vertically.

 

This "Short cut" actually creates a lot more work for me as now I have to go back and clean up all the other states in my state machine that are messy now.

 

CaseCapture.PNG

 

(As already hinted here, I think this deserves a seperate idea).

 

Property nodes have many items that accept color data (cursor color, plot color, bg color, etc). When right-clicking these and "create constant|control|indicator", we get a generic U32 type. Instead, we want a colorbox! Even more complex color structures, e.g. (colors[4] of a boolean) should have colorboxes as the innermost elements.

 

In all instances I have ever used these properties, I ended up replacing the U32 with colorboxes for code readability and simplicity.

 

Idea: when creating an input or output (constant, control, indicator) on any color property, we should get a colorbox (control, constant, indicator) instead of a plain U32 numeric. 

 

color.pngcolor.better.png

In many programs you can open/close all children (neighbours?) of a Tree node by holding control. It'd be nice it that worked in LV as well. (atleast it doesn't in 2019)

I mean 1 level down, not _all_ if there's several.

Yamaeda_0-1746618810697.png

Ctrl+click the '+' and it should open all the neighbour classes, if it's open all should be closed. 

If you copy a group of controls/indicators from a front panel to another, the layout of their terminals on the block diagram is not maintained (instead it is typically messy...)

Vice versa: If you copy terminals from a block diagram to block diagram the block diagram remains the same, but the control layout is messed up.

 

Why not just keep both as they were when copying?

 

 

Bonus-idea: If you try to fix this by using the diagram clean-up function controls with the same name, but an iterative suffix (which the IDE is able to automatically generate itself as well, so it has a relation to it alread) the clean-up ignores the order of the names when ordering the controls...(so it might stack them nicely, but then control ...<n+1> is not put after/below ...<n> e.g. Perhaps it could be a bit more intelligent and include that in the ordering algorithm too?

Editing the Font Styles and Size of a text, can't it be Simpler? rather than a lot of mouse clicks each time??

 

Many had suggested the use of Key board shortcuts, but it may be used for some other things. But Why shouldnt we use a dialogue box instead?

 

The problem is lot of mouse clicks to go to Dialogue font, Styles/size and then to the respective selection like,

Problem.png

 

The Key board shortcuts are being used for other functions., But Why shouldnt we have solution like this??

 

remedy.png

 

I am not sure whether it can be done or someone already suggested., but i didnt come accross anything like this when i searched for.

 

Thank You..

This drives me crazy...  I've noticed that if I have some code on my block diagram (or controls on my front panel) the scroll bars indicate that there is more stuff outside the view of the window that can't be seen.  It would be nice if the scroll bars only activated if there was actually code outside of the screen to be found.  Every time I see this, my OCD kicks in and makes me try to move my diagram to show the hidden code, only to realize that LabVIEW is just messing with me...

 

Of course an image is worth 1024 words..

 

gotcha.png

This is a really basic thing, but it would be helpful if the qualified name (as seen in VI Properties) was enabled so it could be copy and pasted into documentation.

 

When I'm writing detailed documentation to tell other developers how the software works I often use the qualified name as opposed to VI name. For example "Send Creep Command.vi" doesn't tell the developer where to find it, but "Motion Control UI.lvlib:Motion Card 2 Data.lvclass:Send Creep Command.vi" does.

 

McQuillan_0-1642064820004.png

 

I would be happy with the string being enabled (so it can be selected and copied), or a button that copies the string into clipboard.

 

It'd be usefull for develloper and especially application user to improve graph control by adding to Graph direct access to Plot Visible property on plot legend.

 

For the time being, you have to go to color and choose transparent or to change visible property dynamically.

 

I propose control like that ... but we could find another idea to access Visible property.

All plot visible Selected plots visible

 

 

It would be nice if you could change a selected font style by using the standard windows (MS office) shortcuts, such as CTRL-B for bold and CTRL-U for underline.  This would save many mouse clicks.

 

I realize that many people don't use Windows, so maybe it could be customized in the .ini file or would be dependent on what OS your are running.

 

font styles.PNG

Since most (if not all) controls and indicators can be moved around with "position" property node programatically, the X and Y coordinates on the front panel are useful information to have.

As of right now, users have to adjust the position values by trial and error to know what values suit the UI, or maybe make a program to capture the mouse position programatically.

 

So I've been getting feedbacks from customer about a function where one can view the coordinates of the mouse all of the time. (meaning no programming is necessary)

I was thinking about two methods (see attached)

 mouse coordinates FP.png

 

1. Show coordinates along with the mouse

2. Show coordinates at the bottom of the pane

 

Thanks,

 

 

 

For example, when you probe an array, the "Probe Display" only shows the first value of the array. A lot of times, I would like to see a few elements in the array, somewhat like resizing arrays on the front panel. This would be useful for strings, numerics, and clusters as well.

 

Current:

untitled.PNG

 

Suggested:

Suggested.png

Currently (in LabVIEW 2010), you can add labels to wires. Hurray!!

But it's painful. Boooo!

Curently => Right-Click wire, navigate to sub-menu of Show>>Label

 

It should be as easy as adding free text to block diagrams or front panels. For example: If your auto-tool is on then just double-click on freespace to add text.

So we should make it just as easy to add labels to wires:

 

  • Step 1: Single-Select Wire
  • Step 2: Start Typing
  • Step 3: Profits!
We don't need no stinkin' right-click menus.
PS: I am proposing a single click on the wire instead of double-click because that performs a different action.