LabVIEW Idea Exchange

Being able to set the default target build folder for anything I build in LabVIEW would be a nice convenience for me.  Currently, when a new build is created the default path is relative as "..\builds" from the current project folder.  I would like to be able to change the default to a physical root path to something like "C:\Users\<username>\LabVIEW Builds\".

Back in the day (up to LV8.6) there was an option to enable or disable the ability to delete FP controls by deleting their BD terminals.

This was both great and very annoying which made it hard to decide to leave it on or off.  I had a slight lean toward off with its previous incarnation.  Now you have to set an ini key to get this behavior: copyDeleteFPDCOFromFPTerm = True/False.  It was great when you wanted to delete a structure or group of objects in a BD, but save the controls.  It was annoying when you actually wanted to delete the control from the BD.

I do not want this back as is (as was?).  I would prefer a small change.

The default setting should be to blast everything as happens now.  Same as setting the old option to True.

The new setting should behave as follows:  If a selection contains more than control terminals, then everything but the terminals should be deleted.  The terminals should be selected though.  A selection containing only one or more terminals would result in deletion of the controls. 

In this way, let's say you are deleting a structure with some controls inside.  Select the structure and delete it.  You should be left with a selection containing the terminals which were inside.  Delete a second time to get rid of them, or move on if you would like them preserved.  Selecting a terminal and deleting it works normally.
 

I know that this idea exists, but it was submitted in 2009 and I haven't seen any progress in this area. The bottom line is that we need a better way to support different languages in built applications. Importing/exporting strings is tedious and there is no good way to work with these files.

My suggestion is another attribute for every control which contains the name of a string in a language file. I've chosen to show it here similar to php, but any other way to denote that it's a localized string could be used, maybe a different color.

In this example, there would be a string with the name "control1" in each language file that gets loaded based on what language is selected.

There should also be a way to add a "free localized label" to the front panel and a "localized string constant" to the block diagram. This way you can use string names in labels and constants that will be replaced with localized strings from the current language file at run time.

The file could be simple xml:

<string name="control1">
  <text>Input Number</text>
</string>
<string name="fileNotFound">
  <text>The file you selected does not exist</text>
</string>
<string name="okButton">
  <text>OK</text>
</string>

An interface to edit language files could be as easy as a dialog box with a 2 column table containing string names and text.

One language file will be the default. The VI should be broken if the string name isn't found in this default file. When changing the language either by the OS default or a property of the application, all localized text is replaced with strings from the new language file. Any that aren't found fall back to the default file.

Most of this is based on the way Android programming handles localization, which makes it incredibly easy to implement.

Hi.

Most nodes in LabVIEW have what is coined 'standard error in functionality', which basically means the node is skipped if an error is present on its error in terminal - like this Defer Panel Updates property node below:

A smaller subset of nodes behave differently if an error is present, usually by running anyway which is the case for the Close Reference primitive for instance.

Sometimes it's desirable to run one of these nodes with standard error in functionality also in case of error, and then one has to resort to something like this clearing the error before the node and bundling the error wires afterwards to maintain dataflow priority:

I suggest a new Run Even If Error option for property and invoke nodes, similar to the Ignore Errors Inside Node option in the context menu:

This could be expanded to other nodes/functions/primitives as well...

...but this time around I'm only suggesting this for property and invoke nodes as that may hit fewer obstacles.

Cheers,

Steen

You can access the data in your class using property nodes.

Currently all you have to do is select "Make available through Property Nodes" when creating your accessor. I think it would be cleaner if there were simply an Access Scope setting on the control like so:

The idea here is that there is no VI behind the scenes. If you later decide that you want to keep the data private, all you have to do is change the setting. You don't have to remember to delete the VI.

I am guessing that the majority of class VIs are simple accessors. This idea will reduce the number of files to create and lug around increasing edit time performance and would make your class libraries load faster.

Many people (myself included) do not prefer property node access because they can be big and clunky. A possible enhancement to this idea is to put a "Universal Accessor" in the Cluster, Class & Variant palette that looks and acts like a polymorphic VI.

[Edit: the polymorphic selectors in the above image should just say 'Numeric' instead of 'Read Numeric' and 'Write Numeric' as that is implied]