LabVIEW Idea Exchange

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

I wish.. many times I wish.. that it was possible to select all text inside the string indicator.

 

Either right click and have "select all text" option or allow Ctrl-A for select all and it would select all the text instead of selecting all control objects on the front panel.

 

For the time being, for indicators that contain huge amounts of text, I write to a text file and then open it using Notepad.  But it's annoying.  I may not know ahead of time just how much text will appear and plan to simply highlight manually and then Ctrl-C onto TextPad.  When there's a huge amount of text, it is not practical to select everything manually and then it's the write to file function.  --- annoying ---

 

A simple feature:  "select all text" and my wishes would come true.

 

I do hope many of you reader agree that this is a needed feature.

Not a ground breaking idea but...

 

currently when I right click a plot, intensity graph, etc and choose properties for a certain axis, the dialog's combo box doesn't default to the correct axis (as shown) which often results in me changing the wrong axis properties without noticing and having to go through the process again.

 

Solution...default the combo box to the correct axis.

 

 

 

 

Option on the build array function to pad concatenated arrays of different sizes with NaN instead of 0.

One of the biggest problems I have with annotations is that they are always placed with a yellow color. This is fine on black backgrounds, but on white / light colours the annotations are almost invisible. The only way around this right now is to continually poll the Annotation List propertyand try to determine if a new annotation has been added and then set its color accordingly.

 

A *WAY* better solution would be to either be able to set the defaults ahead of time, or, as the title of this idea suggests, add an event called Annotation Change or something that could allow us to determine if somebody had added an annotation / changed an existing annotation, etc. This way we could catch the newly created, practically invisible, annotation creation and set it to a more reasonable colour, etc.

I suggest a probe that will be independent of its diagram.

You will probe a wire , than you may close the front panel of the VI containing it without loosing the probe.

The probe will stay active in the "Probe Watch Window".

If you will click on "Find Wire" the block diagram (and the front panel) will be opened.

 

Advantages:

1. Reduce the number of open windows.

2. Probe VIs with Modal appearance.

3. Easily probe VIs that has their front panel placed in a Sub Panel.

 

The current Linux flavor of Labview uses the older XFree86 to render fonts. This produces a pretty sorry rendering of the Labview applications compared to the native Linux applications. The newer versions of Labview should be compiled with the more modern fontconfig support for Linux, which is the default across all distributions.

It would be nice to add a new control/indicator in Labview, which could view and edit the content of a cluster ( recursivly ) in a tree view.

 

The viewer could looks like the Microsoft Dotnet Property grid.

 

propertyGrid.PNG

I would like to be able to make static event registrations for an element that is contained within an array. Note: this is not just a registration of an event that happens to the array, but an event that happens to an element in the array.

 

This can currently be achieved with dynamic event registration, but I would like static event registration for two reasons: less code, and dynamic event registration must occur with a FP showing whereas static event registration never errors (meaning dynamic events can pose a problem for plug-in architectures using SubPanels).

 

 Here's one specific example achieved with the current method of dynamic event registration. I have an array of a cluster that has two elements, but I only want to know when a user clicks on the Boolean.

DynamicEventReg.png

 

I want to be able to statically register that same event, which would look something like this (in 8.6.1):

 

StaticEventSelection.png

 

As a bonus, as part of the event data cluster on the left-hand side of the event structure, I would like an I32 array called "Index" that gives the multi-dimensional index of the item clicked.

Message Edited by Laura F. on 06-03-2010 04:45 PM

Many users already talked about adding new controls and revamp the current ones. In this topic I will address many issues that I have about the Meter control. Even though I like it a lot, it would be nice if it has more flexibility to customize. Here some ideas:

 

1) Color ramp issues:

  •  
    • Is asymmetric: there is a hidden color in the right most side, that can be only be seen when you change what you think is the last color (red). With the “Interpolate color” option off it is very hard to see and change it;

    • Has a limited fixed number of color steps to customize the ramp looks;

    • Cannot be customized in properties window;

    • Strange correlation between the modes on and off of the “Interpolate color” option:

 

Meter control colors.png


 

  •  
    • Enabling an option, the ramp could appear progressively follow the needle:

 

Meter control progressive ramp.png

 

 

2) When resizing, it would be nice to be possible to change the control's aspect ratio making all internal elements proportionally follow the change.

 

 

3) The user could have an option to rotate it in 90 degrees steps, allowing four positions: normal (0 degrees), right (90 degrees), upside down (180 degrees), left (270 degrees):

 

Meter control 90 degrees.png

 

(The numbers on the scale should be rotated and appropriate 3D shadows should be applied)

 

4) The needle course could have a parameter to determine the curvature. A positive number will give the current aspect, let's say convex. Zero will make the needle become a slider. The nice thing of this is that you can start with something looking as a Gauge (very convex), passing to a Meter (slightly convex), to end with a Slider (strait). I doubt that a concave look, with the needle pointing to the center will be useful because the idea is to make the reading as much clear as possible.

 

I'm Sorry I didn't made pictures to illustrate this case because I have no enough skills do it. I tried to be as clear as possible in the text. If anybody needs any additional information, please let me know.

This idea simply extends "Allow References to be wired into Case Selectors" by JackDunaway.  In short, allow paths to be wired directly into a case selector, with one case for "Not a Path", one for "Empty Path", and a third for "Valid Path".  This would often save me small trees of nested cases.

Title says it all really.

 

Instead of having to rely on manually typing <b> and </b>  (I always get the slash direction of the closing b wrong), how about if we could highlight some text and press ctrl-b and it automagically inserts the <b> and </b>.

 

Would be nice if this worked with italics as well 🙂

 

I know ctrl-b is reserved for the BD remove bad wires, but in this context it would be ok...

Discussed here: http://lavag.org/topic/9570-new-wire-type-the-null-wire/

 

 

 

Summary: a right click menu option "Visible Items -> Sequence Container" on all VIs, prims, etc (almost anything on the diagram) to allow us to wire force flow control, without having to wire into/out of the actual node.

The IDE option to show constant folding is extremely powerful, but if you keep it checked, your block diagrams look like you're looking at a blurry CRT. This gets tough on the eyes, so I would appreciate a menu item called "Show Constant Folding" right next to "Show Buffer Allocations" that temporarily flashes the constant folding blurriness.

 

Below is an example of the blurry lines:

 

BlurryConstantFolding.png

It would be nice to be able to configure the File Dialog view. I would like to be able to set the default to show details and sort the files in descending order.

Message Edited by VADave on 09-18-2009 05:29 AM

Having read THIS thread I realised that nearly the only time I ever use a sequence structure is to time code.

 

Then I thought, why shouldn't the Sequence structure have a timing output node (selectable) so that we don't have to manually do this every time we want to test code speed.

 

Then I thought a bit further and thought, why not have this for ALL structures, it's such a useful tool, it could be used for For loops and while lops too.

 

Timing for structures.PNG

Shane.

Hello all,

 

Being accustomed to using the right-click copy and paste text function in most of my other Windows applications (this is a standard feature), I'd much appreciate being able to do this within LabVIEW text fields as well.  Among several places in LabVIEW that would benefit from this, this feature would be an especially useful timesaver while editing the Documentation field (for VI / control / indicator properties etc).

 

Best regards,

Oliver Barrett

www.linkedin.com/in/orbarrett

SubPanels are the life of the party for scalable HMI projects. I use SubPanels inside of SubPanels inside of SubPanels. Currently, when you drop a SubPanel, all you get on the BD is an invoke node:

 

NewSubpanel.png

 

If you delete that one invoke node, you have no indication on the BD whatsoever that the SubPanel still exists! If you have hidden that SubPanel and have no references to it on the BD, it's a nightmare trying to re-show it through the VI server (especially if it's nested, or in a Tab Container). Further, there is no method that allows you to query the SubPanel what VI is currently inserted into it.

 

Here's a suggestion for updating the implementation. The "datatype" of the SubPanel is a VI reference, so you can directly write to it or read from it without an Invoke Node. This also allows the parent to query what VI is currently inserted. The "Insert VI" and "Remove VI" Invoke Nodes could go away (wire null ref for "Remove).

 

NewSubpanelImplementation.png

 

 

Since 1986, when LabVIEW first launched, there has been one constant.  Icons are 32x32 elements. 

 

That made sense on 17inch CRT monitors.  There have been improvements in displays since then but, no corresponding improvement to the Icon resolution. 

 

Isn't it time to change that?

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

 

The Swap Values node only supports a Boolean input on the '?' terminal.

swap-values-error-cluster.png

It should also support an error cluster input, in the same way as the Select node (pictured) and many other nodes with Boolean inputs.