LabVIEW Idea Exchange

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

Let's say I have a class with a few public VIs, and several private VIs and typedefs:

_carl_0-1674746142961.png

Assuming I'm not working on a VI within the class, If I'm using this class on a block diagram, I can only use the public VIs.

 

However, if I right-click on the class wire, and go to the auto-generated class palette, it shows everything.  This can be absolutely overwhelming with larger classes.  Why not scope this palette appropriately?

_carl_1-1674746918911.png

 

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)

 

(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

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

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..

By default, overrides of interface methods with the default dynamic dispatch connector pane (object in/out and error in/out) look like this:

 

Current.png

This means that the default override of interface methods do nothing EXCEPT DROP INCOMING ERRORS, which is bug territory imo.  Ideally, they would be scripted to look something like this:

 

Ideal.png

Yes, I know I probably can mess with the project provider to get this.  No, I don't want to have to do that! 🙂

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

 

 

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,

 

 

 

I have wasted days weeks of my life tracking down why dependencies are loaded in LabVIEW.

 

This is because the "Why is this item in Dependencies?" tool isn't particularly useful in larger projects.  And it isn't particularly useful because it highlights any file in your project (and not in the dependencies) that is dependent (no matter how indirectly) on the chosen file.

 

In this example, if I click on "Why is this item in Dependencies?" on library C, I get pointed to a VI in the project (A.a) which has a very indirect dependency on library C.

_carl_3-1677608632240.png

 

It would be far more useful to me if I instead only got shown the VIs that directly depended on my dependency (even if they were in dependencies themselves).  If I then wanted to follow this up the chain, I could just click on "Why is this item in Dependencies?" again, but on the found item.

_carl_4-1677608937189.png

 

 

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

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

I´m not to fond of the native Boolean constants and their ability to change value by just a mouse click. To me that is not a behaviour of a constant. What if Pi could be changed to e with a mouse click?

The issue is that when clicking around and cleaning up a messy diagram you may by mistake change a Boolean constant without noticing.

I would like to have native immutable Boolean constants like the ones I´ve implemented with two small VIs. My artwork is perhaps not the best, better ideas are up for anyone´s suggestion.

 

CuriousSwede_0-1702651324354.png

 

The help page, that is supposed to provide a starting point for the developers on creating readable, high quality code in LabVIEW seems to be unchanged for quite some time: LabVIEW Style Checklist - NI. 

At different workplaces (including NI) and different teams I have seen different implementations of such guides, many of which included extra "rules".

One such example is the file naming convention:

  • Using spaces for separating words.
  • Using Libraries to namespace VIs instead of including the noun in every related VI.

These are the most prominent examples I can come up with from the top of my head, but I'm sure that there are more.

 

I'm curious if an updated version exists somewhere that could be used to replace the above refenced help page?

If there is not, then I think could we collect some ideas here for updating this document.

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.

 

(Note that this idea has already been proposed and auto-declined. So I'm trying again, this time with a different UX, and pictures!)

 

I've got some code on my diagram:
1.png

 

I need to wrap the code in a case structure, so I do:
2.png

 

Then I connect a Boolean wire to the selector terminal and go on my merry wiring way. Unfortunately, I forgot to consider the fact that I need this code to run in the FALSE case, not the TRUE case. But since nothing is broken in my code, I don't realize my mistake until I start running things. I've made this mistake so many times over the years (the most recent being tonight), that I've decided to propose a solution.

 

There are plenty of times that I want the wrapped code to be in the TRUE case. There are also plenty of times I want the wrapped code to be in the FALSE case. With no obvious default that makes sense most of the time, here's what I propose:

 

If you interactively drop a case structure by dragging a rectangle around *existing* code, we float a button over where you let go of the mouse and give you a chance to make the visible frame the FALSE case instead of the TRUE case:

3.png

(I suck at Microsoft Paint, I'm sure somebody can come up with a better looking button or glyph)

 

If you click that button, then the case structure turns to the FALSE case. If you do *anything else*, the button goes away and the case stays TRUE.

 

With this proposed change, any time I wrap existing diagram code with a case structure, I'll be forced to think about whether the case needs to be TRUE or FALSE. And I'm given an easy out if it's supposed to be the TRUE case.

It would be nice if NI added "Mouse Scroll" (and its counterpart filter event) to the supported events. Today, you can do this by using the mouse input VIs in a separate loop and polling, but that's not a very nice solution.

I would like to have the possibility to "negate" some comparison functions such as "Empty String/Path?". This can avoid to add the "Not" operator.

The picture below is a possible implementation. The dot on the input (on the output ok also) is showing the negation.

Labview Idea.png

This might be good to be implemented for the following functions:

Labview Idea 2.png

The VI Properties window allows to select between local help file and Web-based Help URL.

 

Loc_fr_0-1718700568074.png

 

LabVIEW Class, Library and Project doesn't allow to use Web-based URL.

 

Loc_fr_1-1718700590702.png

 

Loc_fr_2-1718700613471.png

 

The idea is to have the same behavior for all source file.

The default LabVIEW environment option should not show terminals as an icon. 

 

IconTerminals.png

Pressing Shift and dragging an object with the mouse make it move only horizontally or vertically. Great!

 

Unfortunately Labview decides which direction to move (horizontally or vertically) based on the first pixel the mouse moves. So, if you want to move something horizontally, but while clicking your mouse moves one pixel vertically, you're stuck with that direction and can start over again. ☹️

 

"Normal" applications decide the direction to move based on the ratio of x/y mouse movement: If the mouse moved more in vertical direction, the user obviously wants to move that way, if the mouse moved more in horizontal direction, then that is the user's intent. This means you can switch the direction while dragging and you're not stuck to one direction!

 

PLEASE modify the annoying behavior of Labview accordingly!