LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

HTML Control

I would like a control/indicator which supports HTML formatting for display and documentation. There have been a couple of previous similar requests, here and here, but nothing specific to HTML (although jlocanis has been consistent in his comments on these previous requests asking for HTML formatting).

I would envision a control where you enter HTML and can change the display from the HTML to the rendered text easily, similar to the multiple modes available on current text controls.

Why HTML and not just more formatting options?

Why reinvent the wheel. HTML has been around for decades and works well.
You can mix fonts, localizations, superscript/subscript, symbols, etc. within HTML, allowing much more flexibility when documenting front panels.
HTML is platform agnostic

As has been said in other requests, extending HTML support to captions, labels, etc. would also be nice, but secondary.

View All (3)

Move front panel elements by x pixels

Looping Input Tunnels!

When autoindexing on a WHILE loop input tunnel, we get the default value for the datatype after we run out of elements on the autoindexing array. I can think of several scenarios where it would be useful to simply start over with the input array.

I propose a new input tunnel type (looping) which would do exactly that: index the elements to the end of the array, then start over from the beginning, ad infinitum (or until the loop stops).

(The same would of course also be useful for FOR loops. Here it would not be used to determine the loop count, because it never runs out of elements.)

Here's how it could look like in the code. (On the right, I show explicit functional equivalents).

View All (2)

One of the most common operations performed on arrays is to determine whether an element is found inside the array or not.

There should be a function that is dedicated to this fundamental operation. My workaround is to use the "Search 1D Array" function followed by a "Greater Or Equal To 0?" function, as seen below. While it only takes a few seconds to drop the geqz function using Quick Drop, it's still slightly frustrating that this is necessary.

The set and map data types rightly have been given the "Element of Set?" and "Look In Map" functions. An equivalent should be provided for arrays.

Element of Array - edited.png

Thanks!

View All (3)

Currently in LabVIEW you can have a top-level palette (Programming, Measurement I/O, etc) automatically populate based on .mnu files existing in the folder structure at <LabVIEW>\menus\Categories\. However you cannot do this with the sub-palettes such as Arrays, File I/O etc.

I propose to allow auto-populating palettes for all LabVIEW palettes so developers can place their own palette within the appropriate LabVIEW palette for their functions. One example is OpenG and MGI each have a palette of Array functions. They are currently placed in a top-level OpenG\Array or MGI\Array location. If we could sync these folders, we could place each of the array palettes under the Programming\Array palettes:

Simply by dropping their corresponding mnu files here:

Thoughts? Discussion on LAVA that spawned this idea is here.

View All (7)

Tab controls can be scaled to fit a pane, and that's great.

The problem is when you have objects inside a tab control. For instance: a sub-panel container or a multicolumn listbox.

Unfortunately, these items can only be set to fit/scale to pane, and not to the bounding area of the tab control.

I propose an idea to allow an object to be set to scale with a tab control's page. This will allow the tab control to scale with a pane. Embedding a sub-panel container into a tab's page will allow a great amount of configuration since the dynamically loaded vi can handle scaling on it's own. (hint: you can then have splitters inside a tab control)

View All (7)

Alpha Channel in Picture Control

View All (2)

My LV intellisense prototype has been telling me something very interesting recently. When I use it on a Boolean to 0,1 node, it really, really thinks I want to put in an I32 numeric conversion. Looking deeper, almost everytime I forgo the I32 conversion I am utilizing an implicit coercion. What I have not wanted, probably since the LV4 days is an I16.

The following suggestion is a marginal improvement:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Change-Output-Representation-on-quot-Boolean-to-0-1-quot/idi-p/987671

I like output configuration myself, but it can be easily hidden from beginners, and not-quite-beginners alike:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Output-Configuration-for-the-Compound-Arithmetic-node/idc-p/1540966#M11889

And teaching people about it is not enough sometimes:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Output-Configuration-for-Add-Multiply-Array-Elements/idc-p/1944351#M17628

So I suggest skipping the middle man and allowing the numeric conversion functions to accept booleans directly. So simple even a text programmer can do it.

View All (3)

GitHub is amazing.

Figured that deserved to be on its own line just to let it sink in to the importance of this idea. Version control is no longer something only used by professionally trained software engineers. It's here for the masses; for the graphical design artists, animators, document writers. GitHub has a really cool web front-end to version control and brought sanity to DVCS (maybe bitbucket deserves some credit as well). It has championed a simplistic work-flow via pull-requests: GitHub Flow. It supports Issues for reporting bugs or other issues, and has an assortment of other collaboration features that make GitHub amazing.

GitHub (I don't mean git) integration with LabVIEW would demonstrate the power of Graphical Programming to the world.

Again, let that one sink in. There are 3 tenants of GitHub integration that LabVIEW must achieve:

1) Display the image of the block diagram and possibly front panel on GitHub when viewing a repository. Isn't it embarrassing that JKI State Machine Objects has to resort to putting images of VIs in the repo because GitHub can't render the VIs block diagram source?

2) NI must give away graphical diff and convince GitHub to run it. GitHub shows diffs on the web; Source Tree shows diffs in its tool. It's decision circa 1990 to not give Diff and Merge away with the basic version of LabVIEW. To think of diff/merge as advanced software engineering tools is a thought stuck in the past. LabVIEW needs its graphical diff shown within GitHub on a source file's history.

As a side note, vote for a version agnostic Diff/Merge idea here.

3) VI merge needs outstanding auto-merge capability that is built into pull-request merges. When creating a pull-request on GitHub, you'll see this statement (possibly), "Able to merge. These branches can be automatically merged." To work well in a DVCS multi-contributor, possibly open-source environment, the language needs superior auto-merge capability. Pretty much all other languages get it for free because they are text.

Keep in mind that NI will need a partnership with GitHub to accomplish this; however, this type of thing is not unprecedented on file type (maybe unprecedented with a proprietary langauge...). Just take a look at GitHub's ability to Render and Diff Images and GitHub's ability to Display Jupyter Notebooks (formerly IPython Notebooks).

Interactive Application Builder API

Currently, when you programmatically build an application using the "Build" VI of the App Builder API, you have no feedback (such as build details, progress percentage, warnings, errors...) and no ability to cancel while it builds.

So you have no idea how long it will take to build and cannot cancel if it takes too long.

It would be great to have these interactions, just like with the manual build:

The Build VI could have 2 notifiers or user events as additional inputs:

- 1 to receive build details, progress percentage, warnings and errors

- 1 to send the Cancel command

These additional inputs would be optional and default to invalid refnums, which would mean "do not use the feature".

View All (1)

include or exclude code in loop

View All (1)

The database toolkit is limted by the database variant to data function. It can only cast to a labview datatype as long as you wire that datatype to the type input. This means that you have to know the datatype of any SQL query in advance (or convert to string). It would be very useful if the function would also accept a variant datatype. This way it would be possible to cast any complex type into labview datatype, without the need of a predefined cluster.

Image - casting the database input with a the variant type input (circled) doesn't work

View All (1)

When using Block diagram constants wired to Sub VI's, some times we prefer them to be placed exactly below or above the sub VI when they are connected to the bottom and top terminals respectively. This is just to compress the code, so that block diagram looks neat.

When using LabVIEW Code Cleanup

Prefered - would make code cleaner

For this it will be great if we have terminals for constants from top and bottom also. So every constant will have three terminals top,bottom and the ususal one to the right. When user wires to any one of this terminal the other two can become disabled, this will make sure user connects only one wire to the constant. I guess people wont prefer left terminal.

So our new constants will look like this:

At any time only one of these terminal will be active like this:

Hope I'm not duplicating ideas already in this forums (couldn't get to read all the ideas)

As briefly outlined here already, The "File...Save All" menu entry is currently very dangerous and can lead to unintentional damages that are difficult to repair.

The "Save All" entry is very close to the "Save As ..." entry which looks similar, but is used if we don't want to overwrite any existing VI, i.e. exactly the opposite functionality! A small inaccuracy of the mouse can easily select one for the other, with potentially damaging results.

If you don't believe me, create a new VI and place e.g. exponential fit on the block diagram. Double-click the subVI for editing and move one of the terminals by a few pixels. Now go to the toplevel VI and select "file...save All". Notice that the system VI has been re-saved without warning with the changes you just made. If the changes would have been more serious, the entire LabVIEW installation would be corrupted, because it now contains a subVI with altered or broken functionality.

"save all" is not used very often, so a confirmation dialog would probably be OK.
"save all" should exclude everything in vi.lib unless specifically told not to.

Here's how the suggested default confirmation dialog could look like.

Idea Summary: The "Save All" menu item should be renamed to "Save All..." and should open a confirmation dialog before the final action is carried out.

View All (2)

We're all familiar with how fast programming in LabVIEW can be when using the right click menu to quickly access the associated palettes of the function we've right clicked over. Below, we can see that right clicking on the DAQmx Create Virtual Channels VI gives us direct access to the DAQmx - Data Acquisition palette. This is a lot faster than manually navigating to the Functions Palette to get the same result.

However, nothing similar exists for when programming in LabVIEW Object Oriented Programming (LVOOP). Development for LVOOP programmers would speed up dramatically if they didn't have to switch back and forth between their VI and the project window when making use of VIs from their class library.

The idea is shown below. On the left, we have the current Right Click context menu available in LabVIEW. On the right, the suggestion; the programmer is able to search through all of the VIs that are accessible to the class without having to scroll through the Project Window.

View All (4)

Force Recompile option in Mass Compile

LabVIEW is awesome. But sometimes things don't go quite right, and when something isn't quite right somewhere (maybe a bad bit of binary) it would be great to be able to recompile your code. Mass Compile is great for upcompiling from older major versions, but will ignore VIs that are already compiled in the current version. What I'd like to see is a "Force Recompile" flag in Mass Compile to ensure all identified VIs are most definitely recompiled, especially useful when you call Mass Compile from the shortcut menu in Project view.

Yes, it could take some time, but less time than scripting it and you can use the time to make yourself a nice cup of hot British tea.

View All (2)

How you ever had to design a SQL query? Probably

Usually I design these in MS SQL Server Management Studio, because its easy to test there. And I like that the sql code is colored, so its easy to see whats going on.

However, when I copy it into a string constant, the colors are gone:

But I noticed, that if I copy sql code into a mail or a document, the formatting from MS SQL Server Management Studio is preserved.

That is because the program stores RTF (rich text format) information on the clipboard.

Wouldnt It be nice if there was an 'Paste Special' or Quick Drop feature that preserved the RTF formatting when pasting text into a string constant or a documentation label?

Then it could look like this:

If you think that this could be a nice feature, then kudo this idea

View All (7)

Allow pressing 'n' and 's' for Save/Don't Save at VI close.

When closing a VI with unsaved changes, and you get the ”save changes before closing” dialog, you cannot use the keyboard and just press 'n' for no or 's' for save like in every other applications. You have to move your mouse and click, which is so much slower and less ergonomic than just pressing 'n'.

Look at any other application, for example Notepad, npp and OpenOffice:

LabVIEW should be more standardized on keyboard control.

This "complaint" goes for many more dialogs (all?) in LabView. It's just not keyboard friendly.

/Thomas

LabVIEW Idea Exchange

HTML Control

Move front panel elements by x pixels

Looping Input Tunnels!

Add "Element of Array?" function to Array palette

Allow sub-palettes to automatically populate with mnus placed in LabVIEW menus folder

Control reference Size improvement for space saving

Ability to fit/scale object within tab control page

Alpha Channel in Picture Control

Numeric conversions should accept boolean inputs

GitHub First Class Integration with LabVIEW

Warning case in Error/No error case structure

Interactive Application Builder API

include or exclude code in loop

dynamic database variant to data with variant type input

Top and Bottom Terminal directions for constants

"Save All" needs a soft barrier to prevent accidental use

Quick Access to a LVOOP Class Library via the Right Click Menu

Force Recompile option in Mass Compile

Add Option for Preserving RTF formatting from Clipboard when Pasting into String Constant or Labels

Allow pressing 'n' and 's' for Save/Don't Save at VI close.