LabVIEW Idea Exchange

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

According to the LabVIEW 2013 readme file (see attached image), NI installs a so called NI Launcher to work around serious shortcoming in the Windows 8 start menu. 

 

This is an essential tool because the Windows 8 start menu is flat (non-hierarchical) and if there are many NI products installed, the "all apps" screen shows pages and pages of tiles of e.g pdf help documents and it is impossible to find anything without scrolling forever.

 

Unfortunately, the NI Launcher functionality is quite limited to what we were used to be able to do in e.g. the Windows 7 start menu. All we can do is browse and launch a NI application.

 

While the readme suggest to pin often used program to the desktop, taskbar, or start screen, we can only do this by finding the icon on the Windows 8 "all apps" start screen first, where we can easily get lost if many NI products are installed! Yes, believe me, it is very tedious!!!

 

I suggest to add several right-click options to each entry directly in the NI launcher (similar to what we see in the windows 7 start menu):

 

  • open
  • pin to task bar (very important!)
  • open file location
  • troubleshoot compatibility
  • run as administrator
  • pin to start menu
  • ...
  •  (anything that is easily possible to implement)

 Idea summary: NI Launcher should have right-click options for each entry similar to the Windows 7 start menu.

 

 

 

 

I often use ctrl+f to find a string of text in my vis.  When the search results come up, I have to click on each one to find the instance that I am lookiing for.  Everytime when I check on a vi, the vi would open, and I will end up having way too many vi opened.  It would be nice if when I click on a search result, a partial image would come up to show me what the search result is like without opening the vi. 

I use typdefs for almost any data type I define in a program.  Most of the time I am concerned with the data only so a standard typdef is perfect.  sometimes I want to also have the look (properties) of the cluster or control stay the same throughout the code.  A strict typdef does this, but then causes problems like I cant change the properties at runtime.

I would like the ability to change the master typedef and update all instances to PROPERTY changes (ie size or color scheme...).  The current work-around is to temporary save the typdef as strict, close the typdef (causes the propertie changes to update) and then reopen the typdef make it a non-strict typdef and then save and close again.

 

There should be a synchronize option on typdefs.  Turn it on and the look of the typdef will be synchronized, turn it off and you have a standard typdef.

 

 

This Idea applies to all Libraries but my main Use Case relates to Class Libraries

 

I am not sure how everyone arranges there Classes, from trolling online it seems common that non-publically scoped methods tend to get placed in their own Virtual Folder and public methods are at the top-level. 

 For example:

 

21672i8DF9E7B8B93A8490

 

Unless my Class only has a few methods I would take a similar approach however, most of the time I like to categorize them in more detail. The reason being this is my palette from where I choose my methods, and I like to group them using the following logic so that I can get as much information visually out of the organisation / layout of the Class. I like to have the only top-level method as the constructor if there is one (so I can see that there is one or not for that Class).

I only create the Virtual Folders I need, but usually there are a mix from the follow example:

 

21674iC695C8CF5C268BEE

 

The problem I have with the current design is that I don't know whether I have scoped my public methods correctly, as I could have forgotten and they are still left not specified - which is the default when you create a new Virtual Folder

 

21676iAB6ED5F8E26BA877

 

Currently there is no way to tell the difference from the above two Virtual Folders unless you right click on them or possibly look at the contents.

This is not great as there is potential that I could have scoped things wrong which normally leads to me having to check or recheck the scope is correct.

 

21678iF61DE0BD73C6A4AD

 

As LabVIEW is graphical by nature, it would be much nicer if I could visually see a public scope glyph to differentiate it from a not specified Virtual Folder.

I selected the color green as it is a natural opposite to red (private) and has not been used yet.

For example:

 

21680iDEBCDA19ED6B9DB4

 

Therefore, my original implementation would look like the below, and I can straight away see if I have scoped the public folders correctly.

 

21682iC59F6703EC013513

 

I am sure there was a reason not to include it originally.

I am interested to why and if there is a good reason not to show this too.

Lots of ideas for different enhancements to the old trust For-Loop.

 

21165i060333E718DE224C

 

I propose leaving everything the way it is.

 

This is needed as a counter-weight to the multitude of "enhanced" for-loop suggestions out there.

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-Iterators-with-Loops/idi-p/967321

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Start-Step-Stop-quot-structure-on-For-loops/idi-p...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/for-loop-increment/idi-p/1097818

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Reverse-Iteration-Terminal-in-For-Loop/idi-p/1174449

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Real-For-Loop/idi-p/1211713

 

Spoiler

Some of the proposed versions I like but it feels like no matter which version would be implemented, 80% will be disappointed.

Spoiler

There are also some times I just think we're getting lazy as programmers

Spoiler

or Maybe Altenbach's drive for efficiency has affected us all!

Spoiler

I wonder how deep the rabbit hole goes?

 

Shane.

Hello,

 

When using comboboxes with "allowUndefinedString Flag" set to true, it should be nice to be abble 

to catch an event during typing ... and before the control validation.

 

So it could be possible to analyse the typed string ... during writing ... in order to made string check ... enabling or disabling buttons ... etc ...

 

Manu.

Add an additional search scope in the scope dialog.  New scope will be <entire project>.  Right now the widest search scope <All VI's in Application Instance> will not reach VI's that are called by reference, but still in the project.  I have a few co-workers which are "call by reference" happy and it's a pain to track them down manually.

 

 

 

The variant control for LabVIEW shows the "variant type", but there is no way to access this programatically.  A VI or property node should be available to read the OLE Variant type.

 

Variant Control with Type.png

 

A post on on my attempts to access the OLE Variant type is available here.

 

Hello,

 

It should be nice to improve the standard LabVIEW TCP/IP VI library in order to include a way to test if data can be read on a connection.

 

=> Data available VI ... something like ByteAtPort for serial interface.

 

Having such a VI could help to create TCP/IP applications without having to hang and wait for timeouts !

 

Thanks.

 

Manu.

There should be an option (right click on the structure?) to convert a conditional disable to a case structure.

 

Why?

 

a) I often use conditionals to test different algorithms. In several times it finally has been nessecary to implement both (or more) of them into the final application as none of them cover all cases of input data well enough.

b) In other cases It showed that selecting the algorithm should be selectable (e.g. using a INI file or registry entry, a project's global or even from a front panel terminal).

 

In all cases changing the conditional disable to a case using the values from the conditional cases in use as case values would just leave the work to add the input to the case selector input (whereever it comes from).

 

When you inline a subVI it is not the same thing as placing the contents of the VI on the callers block diagram. Almost but not quite.

 

The difference is that all outputs of a VI (inlined or not) become available at the same time when the VI completes execution.

 

 

inlined VI Settings.PNG

 

Set the VI above to inlined and use it in another VI

 

using inlined VI.png

 

The idea is an additional inline setting as follows.

 

inlined VI Settings.PNG

 

Now the VI will truely be inlined as if it were not a sub VI at all.

 

hard inlined VI.png

 

The name "hard inline" is just a suggestion and could be called something else.

 

 

I propose to update the shipped version with a very slight modification to allow the custom definition of stripped levels for the call chain:

 

the optional/recommended input "strip levels" would remove the given amount of VIs in the call chain so that even error-wrapper VIs won't be displayed when the driver throws an error. The function even stays backward compatible 🙂

 

error cluster from error code modified.PNG

 

I'm currently writing some driver wrappers for DLLs and use this VI a lot.So far, I needed to use my own version ...

 

-Benjamin

Hello,

 

I work with many versions of LV on my PC. Can we build in a feature so that when I hover over different .lvproj for .vi files, a tooltip will populate with the version number (LV 2012, LV 2013, etc...)?

 

Cheers!

 

Shawn

In this thread on LAVA, Aristos Queue points out some common usage patterns of the "Not A Number/Path/Refnum?" function that can result in performance problems and/or race conditions.  He recommends either (1) comparing a refnum against a null constant value, or (2) trying the refnum operation you were going to do anyway, and using the error output from that operation to determine if the refnum was valid.

 

I propose a VI Analyzer Toolkit test that checks for this scenario called "Not A Refnum Usage".  The test would return a failure under the following circumstances:

 

  • The input to the "Not A Number/Path/Refnum?" function is a refnum data type.
  • The refnum is any type other than Occurrence.
  • The output of the "Not A Number/Path/Refnum?" function is wired to anything other than a Boolean indicator.

If these conditions are met, the test would return a failure, and would make the two recommendations mentioned above as alternatives to using the "Not A Number/Path/Refnum?" function.

I would like to see an Option for Child Window. This option will useful to keep open FP in Parent FP even when it is moved around, minimized, ect...

I understand LabVIEW dose not support MDI, but simple Child Window option will be helpful. Currently, I am using Windows API to do this, but native supported function/ option can be big help (won’t have to use VI server, Dynamic path builder to check application type vi, exe, llb, and others useful things that needs be done..).

Download All

When developing a  utility to traverse any control using VI Server and save its contents to a file (similar to the OpenG utility using Variant) it is quite challenging to find out the size of the array's data.

 

There are various workarounds, but all of these are relatively tedious and over-complicated.

 

Why don't we have a "array data size" read only value on the property node of an array?

 

This would make things MUCH easier.

 

Shane.

Message Edited by Intaris on 06-12-2009 12:33 PM

I like constant folding.  LabVIEW says "this is going to be a constant".

 

There are some times that I want to see the actual values of the constant.  In the middle of a large VI it can be a pain to de-rail to make a constant, then come back.  It can be easier to look at an array of values for troubleshooting.

 

I wish there was a way to right-click and either show what constant-folding gives, or even convert it to an actual constant.  This is going to change the development side, not the execution side.

 

While it doesn't have to be reversible, it would be nice to know I got it right, then revert it to code, in case I want to vary the generation of values at a future time.

In the spirit of using as little memory as possible I think the default representation for Enums should be U8. Currently when you create a new Enum its representation is set to U16. Since I assume most people rarely have Enums with more than 256 items I would really appreciate it if the default representation were U8 so I don't have to always change it from U16 to U8.

I think there should be some way to select data out of an array on the front panel.

Whe I mean by this, is that you can not click and highlight N x M number of cells, then copy and paste (into notepad, excel, etc).

It doesnt even work if you right click the array, then press 'data operations >> copy data', unless you stay in LabVIEW.

I think everyone's been there before.

 

Working on a project and for some reason from somewhere an Insane Object appears somewhere in the code.  Not a nice thing to have happen.

 

At the moment, it's quite a nasty job trying to track these things down.  Usually most users resort to trial and error in trying to find the culprit.  I myself use the mass compile function to at least narrow down which files have the problems.  Recently there was a post on the Forums highlighting the LabVIEW Object Viewer which seems like something which should be much more accessable.

 

I would like to propose making tools like these more accessable, more usable and maybe adding a tutorial as to how to deal with this.  I also would like to see more sanity checks for the LV code so that we could maybe catch these erros earlier.  How about an error whenever saving a VI so that we can 1) attempt another save in case the error comes from a write error or 2) investigate the problem immediately so that we can rest assured that we have caught the problem early enough to prevent tearing down the whole project.

 

 

Message Edited by Intaris on 06-02-2010 02:29 AM