LabVIEW Idea Exchange

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

It would be nice to be able to change the tab behavior "Skip this control when tabbing" when setting the tab order for the front panel.

 

TabOrder

 

Regards

/Thomas

Wouldn't it be great if you could change the size (and other properties) of your cursor, as you can outside of LabVIEW? Let's bump this idea and see it in a future release of LabVIEW! 

 

size.png

 

 

untitled.PNG

 

OK, so what happens to the index displays if you click the top buttons, the ones with the arrows pointing up?

Spoiler
the Ring and enum indicies DECREMENT

 

I would propose to make the behavior consitant so that UP increments and DOWN decrements

LabVIEW should expose a method that allows you to "drop-down" a combo box programmatically.

 

Something similar to the issue discussed in this KB article:  http://digital.ni.com/public.nsf/allkb/96BD56FE6D416AB5862573BE00811AC2

 

A simple invoke node would be great.

Currently, I have to move each of the control into the cluster, and then I have to spend a lot of time repairing the broken wires in the BD.

 

Is it possible to just select all the controls you need to bundle into the cluster and create a new cluster.

Labview will need to automatically repair those broken wires.

This should work in both BD and FP.

 

It's just like selecting many stuff on the BD and create SubVI!!

new cluster idea.png

I'd like to see this rolled into LabVIEW core: http://lavag.org/topic/13748-discuss-variant-probe/

Right now, this doesn't work:

 

1-26-2011 2-45-25 PM.png

 

I have to add a Convert Units function to make it work:

 

1-26-2011 2-51-21 PM.png

 

It would be cool if the Wait (ms) function were polymorphic, accepting floating point inputs with "units" of time, and performed the unit conversion behind the scenes (and without any coercion dot).

 

Of course, this might require renaming the function to simply "Wait" (w/o "(ms)" qualifier).

Hello,

 

I am looking for possibility to rotate a frontpanel object. I often use labview as a HMI, in this case it wood be nice to rotate an object by value.

 

Is there any one has a solution or the same problem.

 

This is a bit tricky to describe.

 

One of the nice feature of the help window in LabVIEW is that when mousing over a node the help window does size itself (to some extend) to display the help/description associated with that particular node.

 

This is a great feature but there is a specific situation where this is annoying. For instance when you are in the process of wiring a node, depending on the source node help/description the help window may suddenly resize itself to cover your sink (target) node.

 

In that situation you have to either hide the help window (CTRL+H) or move your VI far enough and rewire (see video below).

 

 

 

What I am proposing is to auto hide (or make the help window semi transparent) the help widow when a wire is being lay down and the user get behind the help widow. As soon as the wiring is done the window can be restored to its previous state.

 

I rediscovered a kind of an annoying behavior with multiplot XY-Graphs which appears to have existed since LabVIEW's emergence. Say I want to use the XY-Graph like a curve tracer, thus adding XY data pairs to an existing multiplot XY-Graph by passing the array of array clusters around in loop shift registers and fill in new data as it's produced. This all works well BUT when adding multiple plots in different colors it shows that consecutive plots are always drawn underneath the already existing ones instead of the other way around. I find that new plots should be drawn over already existing ones also according to the sequence shown in the plot legend.
 
If your new plot has the same or similar values than the previous one then the second plot will be hidden underneath the first one. You can only see a second one if the values are different. It's counterintuitive I think and I wonder why it has always been like that.
 
I plead for a XY-Graph option along with a property node to change this so that new plots cover old ones when they intercept. The legend sequence should not be changed because the top to bottom order is correct. 
 
I demo VI of the misbehavior is attached 
 
I hope I get enough support for this to be done. 

Urs

Urs Lauterburg
Physics demonstrator
Physikalisches Institut
University of Bern
Switzerland

self-explanatory.........................

graph4.jpg

I hope LabVIEW wishes to become the next-generation all-purpose programming language that will be used all over the world in all industries.

 

.NET and Java are the dominant Technologies in almost the entire world.  With the introduction of the ability to create a .NET Interop Assembly with LabVIEW 2009, I was very excited because I thought that now I could go back to several former employers and make a convincing argument for them to use LabVIEW.... But then I realized,  yes, I can now expose my code written in LabVIEW to .NET applications, but my code cannot do many things which are standard in those worlds.  For example:

 

I can create a .NET Assembly, but I cannot:

  • inherit .NET classes
  • use generic .NET classes
  • create.NET classes that use generics
  • implement .NET interfaces
  • expose a LabVIEW event to a .NET caller
  • expose a LabVIEW class to a .NET caller 
  • cannot create Office Plugins, or any other Plugin that requires me to implement an interface

 

i.e. almost every single financial institution has an in-house developer that creates various Excel Plug-Ins and Add-Ins, LabVIEW cannot be used to create such a product because LabVIEW cannot inherit from and implement the IDispatcher interface.

 

The CLI - Common Language Infrastructure is an open specification developed by Microsoft tha

 

It allows anybody to create a programming language that creates fully compliant .NET code.  There are 3rd parties that have created products such as ActivePerl and ActivePython, which allow developers to use Perl and Python (and even COBOL!) to create .NET compliant code.  My vision is for LabVIEW to do the same, so that now every single organization in the world that uses any .NET language can also consider using LabVIEW, without having to run into many issues along the way.  Only with full .NET compliance will random worldwide organizations consider writing a portion of there software in LabVIEW before hopefully moving entire projects onto LabVIEW!

Message Edited by John80 on 09-03-2009 01:49 PM

Dear NI,

 

Please fix LabVIEW so that when you right-click on a wire on the block diagram the menu pops up immediately, not after 1 second. Also, while you are fixing that, it would be great if you could fix the speed it takes to open a control/indicator properties configuration dialogue.

 

As far as I can recall these were fine in LV 7, but sometime after that itall started to get a bit sluggish.

 

Thanks!

 

 

 

 

The current behaviour of scrollbars on multicolumn listboxes etc. is that they either show the scrollbar or not - however if there is no scrolling necessary they are greyed out.

 

In most non-LV applications this is not the case; there the scrollbars will hide if they are not needed. Such behaviour can of course be achieved programmatically, however it would be nice if it was coded into the scrollbars.

The IDE would be more consistent if all the toggle-able features were collected together under the "Visible Items" submenu. Photoshopped example of a FOR loop below, but I'm sure there are others. "Show Dynamic Event Terminals" comes to mind...

 

OneOfTheDans_0-1647968497756.png

 

Jim_Kring_0-1607714897568.png

 

Problem Statement

Sometimes, you may want to delete files that are read-only. The Delete primitive outputs an error (Error 😎 when you try to delete a File that's set to read-only. One then has to change the file permissions to writable and retry deleting it. That's a pain. What's even more painful is when you try to delete a folder, recursively, with the Delete function -- passing it a folder path and setting Recursive to TRUE.  In this case, if even a single file inside the folder is set to read-only, then the recursive delete will fail -- now, the developer has to do their own recursion to find the file that's read-only, mark it as writeable and then delete it. OK, convinced this is a pain?  Here's the solution...

Jim_Kring_1-1607715044205.png

 

 

Proposed Solution

Add an input called "Ignore Read-Only" to the "Delete" function that will do all this form me.

 

Note

The OpenG Delete Recursive VI (in the OpenG File Library) has such a feature already. I was excited when LabVIEW implemented a recursive delete and I started using it all over the place (it's nice to write code that doesn't depend on external libraries, when possible) and then... I got bit by this limitation in some random corner cases where files had gotten marked as read-only.

 

Jim_Kring_2-1607715080073.png

 

 

What if you need to run exe as admin mode?

 

Currently Build Specifications is not enought for doing it.

Here you are what you need to do:

 

1. Built the executable

2. Install mt.exe (https://www.microsoft.com/en-us/download/confirmation.aspx?id=8279)
3. Opened cmd as adminstrator and ran mt.exe -inputresource:"Application directory\application.exe" -out:application.manifest
4. Opened application.manifest and changed input="asInvoker" to "requireAdministrator".
5. Saved application.manifest
6. ran mt.exe -manifest:application.manifest -outputresource:"Application directory\application.exe";#1

 

Is it an effective method?

 

It would be better the following:

1. Create Manifest

2. Easy modification in My Application Properties

Capture1.JPG

 

 

Hope it helps to do a more effective LabVIEW!

 

Álvaro

                                                      When a Structure_Case is larger than a screen,


                                           I scroll through the sub-diagrams with "CTRL+mouse wheel",


                                                The problem is that  the selector label is no longer visible.

 

                              SR1.png

 

 

                     

             The selector label should always be in the middle of the visible part of the Case structure.

                                                                                         like this,

 

                   SR2.png

It would be nice, if you could resize a structure to a minimum (a small padding should be left over) with simply double-klicking on these small blue "resize-squares". It should function with every "resize-square".

resize structure.png

In LabVIEW, data types generally propagate downstream. If you wire a cluster output into an "unbundle" node then the IDE lends a hand by resizing the unbundle node automatically. Nice.

typePropogation1.png

 

I would like to see the same behaviour applied to the "bundle" node. In this case the type information needs to travel upstream. Yes, backwards!

typePropogation2.png

 

Excuse the overly simplistic example... Yes, I know we could just connect the bundle node's middle terminal in this case, but it illustrates the concept.

 

A more realistic use case would be nested clusters or nested private data in a class. In this case propagating the type upstream could be quite handy when bundling various sub-clusters:

typePropogation3.png

 

Note: There are not many situations where the IDE will allow a data type to propagate upstream, but there is already some precedent for this: In certain situations the "Variant to Data" function will automatically assume the type of the wire connected to its output.