LabVIEW Idea Exchange

Renaming files with F2 or the context menue entry "rename" is easy - as long as the file is a LabView or NI-File. But if it is just a simple *.txt, *.pdf, ... file it is not possible. Please add this function! - thanks.

With the increasing size of the LabVIEW ecosystem, there is a growing number of third party tools written in LabVIEW that are versioned independently from LabVIEW's version number.  For example, I could create an API that has versions 1.0, 2.0, and 3.0, and all three versions could be compatible with LabVIEW 2009 or later.  Tools like VI Package Manager make it easy for content creators to publish multiple versions of an API, and for users to upgrade and downgrade between those versions.  However, this ease of use disappears if significant changes have been made to the VIs in an API, such as:

• Changing VI connector panes
• Renaming or moving VIs on disk
• Adding VIs to a library

If any of the above changes are made to VIs in an API between versions, it can become impossible to migrate code between the two versions without a lot of manual searching, replacing, and relinking.

LabVIEW should provide a mechanism to define mappings between old and new versions of third party toolkit VIs.  Consider the case where I make the following changes to a VI from my toolkit:

	Version 1.0	Version 2.0
VI Path	<userlib>\mytoolkit\CompRes.vi	<vilib>\mytoolkit\Compute Result.vi
Owning Library	none	Mytoolkit.lvlib
Connector Pane

I should be able to create a mapping file included with version 2.0 of the toolkit that describes the changes made between versions 1.0 and 2.0 of the VI.  This way someone could write an application that calls version 1.0 of the VI, then upgrade their toolkit to version 2.0, and the application source code would be able to find, load, and relink version 2.0 of the VI without any hassle.

I think it is very difficult to make a UI that runs on Windows and interacts with targets. Here are two suggestions to improve this:

1. We currently can't have \c\ format style in a file path control on windows. It would be nice to allow user to specify the OS syntax to use instead of assuming it should always be the local sytax.

2. The icing on the cake would be to have the File Path Control support a property node for an IP Address so when the user clicks on the browse button, it automatically browses the target (this is already an idea mentioned in the link below) and uses the syntax of the target. This becomes especially useful as we start to have targets that may have an alternative way of browsing files besides FTP. It would be a pain to figure out which SW is installed on the target and use the correct method to enumerate files/folders.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Path-control-of-VI-under-real-time-target-should-brows...

These two features could be implemented by having an enum property node for the File Path Control called Syntax which include options like: Local, Various OSes (Windows, Linux, Mac, etc), or IP Address. If IP Address is specified, another property Node called IP Address will be used to determine what target's OS to use (if it's not specified or invalid, we default to Local).

Hello all,

In the "Glyphs" tab of the VI icon editor, would it be useful to sort glyphs by the ones the developer uses the most?

(I feel like I'm going to get a whopping ten votes for this one, but I had to say it anyway.)

We all likely have glyphs we use all the time, and ones we never use in the "Glyphs" tab of the VI icon editor.  (Does anyone actually use the Wii Remote icons?  They look cool, but have such limited usability.)  I find it mildly frustrating to wade through all of the glyphs every time I go to create icons.  This is because I haven't memorized the sometimes unintuitive keywords.

Thanks for your consideration.

Mr. Jim

I'd like to have an option to allow resize X and Y separately.

Because I only want to allow Y resize, and not X, I need to program an event to detect X resize and restore the original size.
Users don't like it. The resize event is sometimes lost, when keeping the mouse down long, causing no restore to original size.

I would like to have the ability to make a Front Panel background transparent without making the whole window transparent (where the later is currently possible through property nodes).  This one item would expand the UI possibilities.  It would allow for the creation of Front Panels that seem to be borderless similar to many splash screens, about screens, and gadgets.  Below are some industry examples:

Adobe Splash Screen (No border, has shadow, not square)

  Microsoft Word 2010 Splash Screen (No border, rounded corners)

 Resource Meter Windows Gadget (No border, specialized graphic)

Windows Media Center Gadget (Empty-transparent space between two UI elements)

I propose to replace Max & Min for two elements, which we could resize like some array functions for 3, 4, 5,... elements when you know how many you have to compare.

I actually have 5 elements coming from a bundle, I have to do this

Get contents of all XML Node Types:

As a beginner at XML parsing, it would be great if LabVIEW had a VI (like Get Node Text Content) but for every node type (it would get the contents, whatever they may be). 

All node types stated here:

http://www.w3schools.com/dom/dom_nodetype.asp

are possible and may require a different set of property/invoke nodes (some have children, some don't, some have values, some don't... and so on).

Inputs: Node handle

Outputs: Raw node contents (whatever XML is contained within the tags of the Node handle), Value (where applicable), Name (where applicable)

Write general string to XML node type:

It would also be great if there was a VI (or set of VI's) that could take an input (as a string) convert it to the w3 conformant XML.  It's important to use the w3 definition, rather than LabVIEW XML for external compatibility.

Inputs: Node handle, Node Type

Outputs: XML string of Node Type

It would be very useful that RT FIFOs could be of type lvclass as long as the class' private members are of static types (perform the same check that is done for clusters when you try to use them as the type for RT FIFOs).

When deleting linked tunnels, any wires that are only passthroughs between the terminals (i.e. are not wired to anything not linked to it) should be automatically deleted.  This should work regardless of whether the input terminal or the output terminal is deleted.

When multiple output tunnels are linked to the same input tunnel and one is deleted, only the broken portion would be deleted (again unless the wire is connected to something other than another linked tunnel).

A use case for this is when you have a bunch of shift register passthroughs in a queued message handler and decide to combine them into a cluster.  An additional benefit of this is that the broken wires that would remain would point out the code that actually used the linked terminals and would thus likely need to be changed (i.e. wired up to bundle/unbundle by name).

For as long as I've been using LabVIEW, I've often turned to the LabVIEW Help file (which is a compiled HTML file) and found very little help.  I'll search for something simple like "For Loop" and receive 500 (literally, try it for yourself) possible topics, including the Cohen-Coon Autotuning Method, Control in NI-DAQmx, Limit Specification VI, and so on.  These have nothing to do with For Loops.

I'm proposing that the LabVIEW Help be turned into something that is ACTUALLY helpful.  I'm not sure about the best way to do this.  I think that it should still be portable and shouldn't require any Internet access to use (as lots of us cannot access the Internet on our development machines).  I would really enjoy a tool that would allow me to search for something like "For Loop" and receive like 5 topics that all have to do with using a For Loop in LabVIEW.

When debugging (and at many other times), I want to copy data from a probe or control into a text file, Excel, whatever.

For reasons that I am totally unable to fathom, it copies the control as a bitmap. Print screen provides this functionality already. I think copy data should copy text instead!

I wasn't able to find this on the exchange, sorry if I missed it!

I'm a great advocate of commenting code, but with the graphical nature of Labview, you need space on your block diagram to add in a post-it giving your comments. That's great if your block diagram is nice and spread out, but (perhaps due to poor planning/programming) i'm often finding myself getting limited on space. Adding comment labels all over the place takes up even more space and results in the whole block diagram exploding to an often impractical size.

Wouldn't it be nice to be able to do an Excel-type tool-tip, where comments will be hidden until hovered over with the mouse?

Instead:

    hover with mouse -> 

Very often we need to combine both Align and Distribute operations. For example, objects should be aligned by bottom edge and distributed by centers. Right now we can use Ctrl + Shift + A; Ctrl + D hotkeys, but for intensive UI design the floating point window like this will be useful, where all operations combined together:

Different combinations are possible:

This window can be called probably from View->Align & Distribution Window.

Andrey.

I use disable structures and conditional disable structures more and more as my coding starts to spread over multiple targets (Host, RT and FPGA).

I like to include some debugging indicators for my code so that I can (with the proper conditional disable symbols set) debug my code more easily but still remove the bloat for actual release code.

What I have noticed is that controls and indocators which are disabled int his way are NOT accurately represented on the FP.  As such I am surrently unable to determine by looking at the FP of a VI that perhaps half or all of the visible indicators are or are not actually being used in the code.

Even when the code is running, the controls and indicatory which are actually disabled are still visible (and supposedly still available over VI Server for example).  I think these controls should be actually removed or at least have a visual indication that they are diabled on the BD (distinct to the appearance caused by writing to the "Disabled" property of the control).

The LabVIEW help states: "When compiling, LabVIEW does not include any code in the inactive subdiagrams of the Conditional Disable structure" but I question how true this statement really is.

Although these controls are DISABLED (Not present in the source code)........

Here they are.....

This raises issues on the FPGA level more urgently than on the PC side, but I feel the sentiment behind the idea is the same.

Of course things get more compilcated when the controls are connected to the connector pane, but perhaps simply prohibiting the presence of a connector pane terminal in a conditional disable structure would solve that problem.

Shane

I often have code in my apps where some error-out nodes are not wired, simply because the errors are generally not of interest to me or the error wiring would clutter up my block diagram. Typically this happens a lot in UI handling code where a lot of property nodes are used. For these parts I would rely on the automatic error handling for debugging purposes. One of the drawbacks of this method is that program execution is suspended when the automatic error handler kicks in. Even worse if this happens for code that is in a loop. You're only option then would be to abort the app, which e.g. is no good for your reference-based objects, etc.

I would love to have the ability to just specify my own 'Automatic Error Handler', enabling me to decide what to do with the unhandled errors. Just logging them is what first comes to mind, but maybe also do some special stuff depending on the type of error, just like a 'normal' error handler. I want to be in control!

Added values of this is that your application then has a catch-all error handler which enables you to at least log every error that occurs, even if not wired through. (Everyone forgets to wire some error-out that they actually did want to wire one time or another don't they? ;-))

Ofcourse the proposed setting in the image would ideally also be available programmatically by application property nodes.

"A picture is worth a thousand words..."

That's especially true when describing complex interactions of the kind often seen in code.  Currently the block diagram decorations consists of 4 elements: a line, a straight arrow, a frame, and a label.  I can and often do create state diagrams out of those elements, but they look very hacked together (i.e. unprofessional) and are cumbersome to create.  The alternative is to use an external graphics program and paste the image into the block diagram.  I do that sometimes too, but it makes it harder to keep the diagram up to date.

I'd like to see elements added to the decorations palette to help us create graphical comments.  Since state machines are very commonly implemented in Labview, that seems like a good place to start.  How about adding a state decoration and a transition decoration?  The state decoration should allow more formatting flexibility than the label does.  (Like having the first line centered and the rest left justified.)  The transition decoration should be an arrow that allows routing--either smooth curves or point turns.  It should also have a label attached to it for identifying the transition trigger.

Here's an example of a state diagram for some proof of concept code I wrote that I pasted to the block diagram.  I'd like to be able to easily do these kinds of drawings without needing a 3rd party app.