LabVIEW Idea Exchange

It's been great to be able to find Items with No Callers in Project. How about Find Broken VIs as well?

At the moment you can Replace a Missing VI in the Project by popping up on the project item and selecting Replace with... which brings up a file dialog where you can go trolling through directories to locate the missing VI.

I propose the option where you can Replace the Missing VI by navigating the Palette.

This method would be much quicker especially if you have a lot of VIs to replace.

An example use case is that you have refactored code in your project, creating a reuse library seperate to the project and changed the namespacing of the VIs as part of the distribution.

This distributed library is now available in the palette and you want to relink your project back to it.

I imagine it would function simiar to the below:

Get a quick and more clear view of the event handled by an event case

Intead of this:

Get this by a click on the event case number:

It would be really cool if LabVIEW had a String Control with inbuilt Spell Checking functionality available at Run Time.

End users will be able to correct input data whilst developers would not have to implement anything (except for maybe enabling spellcheck as a Property of the String Control) as it would all be handled under the hood.

I am thinking that it would look similar to the operation below:

The standard functionality of spell checkers in browser apps (e.g. IP Board) would be sufficient. The above example is from IP Board's editor and the implementation appears clean and fits the workflow well.

There are two other spell check Ideas here and here but the ideas/discussions are about spell checking in the IDE - this Idea is for Run Time.

Note: This idea could be expanded to other use cases however, the above is my primary one. And yes I ran spell check on this post to avoid any of those comments 

This should be simple....(!?)

I want my user to be able to resize the window but only in one dimension - e.g. drag the right border of the front panel right or left but not allow them to resize the height while the VI is running. (In my current project it just doesn't make sense to allow them to do this).

I have to keep rewriting the front panel size on the resize events but it has ugly side effects (parts of the front panel become visible temporarily until LabVIEW puts the bottom border back, amongst other things).

The VI properties can disable resizing completely but it should be easy to add a couple of sub checkboxes for Height and Width.

I'd like to see those properties reflected in the usual places (property node etc).

Support didn't have a better solution than the code I have but suggested that I put in an idea .... so this is it!

First of all, I know I'm going to get a heck of a lot of flack for this idea. I know how you guys hate changes or additions to core structures

State Machines and Abortable Sequence Structures are very, very powerful. In my opinion, their only downfall is the fact that they require two structures surrounding the code: a Case Structure and a While Loop (or sometimes For Loop) surrounding that. This takes up diagram space (albeit not an absurd amount) and it is annoying when needing to resize the structures. If you add more code (and are OCD about everything matching up on the BD grid like I am), then you need to resize 2 structures instead of one.

My suggestion is to create a new structure that combines these two structures. I believe that this new structure, if implemented correctly, will reduce the number of overused stacked sequence structures by providing a simple yet intuitive core structure that offers the same functionality with more power. This new structure will also make it easier for non-programmers to become familiar with State Machines and their power.

Here is what the "State Machine" structure would replace:

      --->     becomes  --->           

The S input is a right-click option "Enable State Machine Input" which acts as a shift register and also as the case selector for the state. If "Enable State Machine Input" is disabled, then the iteration terminal i is used as the case selector. The i and Stop If True terminals are shown in every case, and the Stop If True has the option to use default if unwired (False) through another right-click menu (you can see this icon in the 1st "Abortable Sequence" structure). In my example I used an enum as the input, but any valid state machine input would work (string, DBL, boolean, etc.)

This would not be a full replacement for the original architecture: sometimes there is code that needs to be run before or after the state, on every iteration. This new structure would not be able to handle that in a nice way (you'd have to copy the code to every case, and that's just silly).

So, what does everyone think? Where are the flaws? What parts do you like?

Currently it is only possible to hide/unhide the frame of a subpanel by activating the context menu with a right-click.

Please add Frame.Visible to the list of subpanel properties.

Ran across this AGAIN today.  Its pretty annoying and should be fairly simple to implement.  I would suspect that the dev team got a bit rushed and never came back to flesh out the Detail functionality.  Time to post this here I guess.

When building Installers for an updated version of an executable, you can't select whether or not to overwrite the current source files directory. The reason this is a problem is when distributing to computers that need different configuration files that are installed with the original version but have since been customized to the specific computer. If you try to only include certain source files and not others then it still overwrites the entire directory and you lose the files you were trying to save. If there was an option in the Source File Settings window to "Overwrite", it could be automatically checked for the same default functionality but you could uncheck it to allow writing into existing directories.

If you like this idea then give me some Kudos and hopefully we can get it in the next version of LabVIEW!

Peter W.

Applications Engineering

National Instruments

www.ni.com/support