LabVIEW Idea Exchange

I recently submitted (as a bug) the fact that, when I have a control that is type defined (or strictly type defined), the 'Value' property node does not propagate the type definition. The documentation for the 'Value' property states that the data type is "Labview Variant". But... when I use the 'value' property, the data type is always the type of the underlying control, *except* for that, if the control was a type-defined (strict or non-strict) control, the resulting value (indicator, control, or constant) is disconnected from the typedef.

I *never* get the purple line and data type 'variant' that the documentation would suggest.

It's my belief that the disconnectiion from the type definition is both incorrect behavior, and a bug... and that the correct way to document the value property is that it returns a data type that matches the underlying control, not the Labview variant data type.

This is especially egregious when you pass a control reference to a SubVI and create a local copy of the indicator, constant, or control that you can use in the SubVI, perhaps with the intent of updating the control passed by reference before returning to the caller. If the control happens to be a cluster that is strictly type defined, and the structure of that contents is changed, the created controls, indicators, and constants derived from the reference will have the OLD cluster definition if the 'value' property disconnected from the strict type definition. This means that the SubVI not only needs to have it's logic updated to match the new cluster definition (if required, it could use elements that didn't change in the cluster definition), but it also means that you have to go back and update each and every control, indicator, and constant because even if the 'value' property now returns the correct contents, the containers you created to hold those contents are now incorrectly typed.

I was told by Labview tech support that:

"this is the way LabVIEW is currently programmed to function. Because of the generality and flexibility of property nodes, they do not maintain their strict type definition once passed through the property node. While the strict type definition and the characteristics of the front panel control/indicator may not be maintained by the property node, the integrity of the data is still intact. The property node coerces the data to fit a type it understands and then writes the data to the control. The data will still be the correct type, will have the correct data, and will have the same looking controls/indicators."

This supports the notion that the documenation ("'value' property returns Labview variant) is simply incorrect. It also support my contention that the type definition disconnection is a bug, is erroneous behavior. I've noticed that *sometimes* the type definition is NOT disconnected, although I have not been able to determine what controls that behavior; but note that in the response to my question from tech support, they state that the "strict type definition ... may not be maintained by the property node" (emphasis added). I think this is a flat-out bug; that the data type MUST propagate; that the connection to a type def (if there is one) is in essence part of the data type, and MUST be maintained.

I want this treated as a bug with an action item to get it fixed.

What do you think??? Should the 'Value' property return typed (and type defined) data, or should it return a Labview variant, as documented???

Hello!

I hold many different revisions of my projects on my PC, and am not currently using Perforce or any other source control.  As the mass compile tool stands now, if I were to mass compile a directory which contained the latest version of my project, it would search through all of the files on my hard drive and link or relink VIs to the first version of files that it finds.  My project would basically link some Vis correctly and to old or outdated versions of VIs or DLLs in some cases. 

I would like to suggest that the mass compile feature in LabVIEW allow the user to specify the folder or hard drive location where the desired source should be located.  Currently we're only able to point towards the directory where the broken links exist.  It would also be nice to have a checkbox feature to include the subdirectories below the top level desired source directory.

Cheers!

Shawn S.

When you create a User Event and add it to an Event Structure as an Event Case, you have new event data nodes available: the reference to the event and the data generated by the user event. Similarily, if you add a Control Event to the Event Structure, you have event data nodes available such as the old value and the new value. See the example of the User Event below: 

However, when you add two events to the same Event Structure Event Case, the UsrEvtRef and Demo Event Data Nodes are no longer available. Only the data nodes that are common between the User Event and the Control Event are available, as shown below: 

This behavior has been observed in LabVIEW 2011 SP1. Customers have expressed interest in being able to access user event data in Event Structure Cases which contain multiple events. 

In LabVIEW 8.0, customers had the ability to modify the default connector pane. However, in LabVIEW 2011 SP1, the default connector pane is fixed to the 4x2x2x4 pattern, and the defaultConPane INI token no longer changes the default connector pane. Customers have expressed interest in being able to modify the default connector pane to prevent needing to change it manually when they are consistently using another connector pane pattern.  

I have two identical VI that take DAQmx signals and put them into a waveform and then use two different methods to select the signals for display in charts on the display. One VI uses the split and merge VIs while the other VI uses the select signals express VIs. They both work the same; however, the split and merge VIs obviously select the signals based on the output index which supplies the signals implicatly, while the express select signals VIs rely on a popup menu to show the signals configured in MAX in a list where the user can then select the needed signals. The idea is great except the VI does not do this all the time!  When the properties dialog box is displayed the first time that the sub VI is used the popup list shows a sort of default list of signals: signal 0 thru signal 7. This is amazing since the input waveform comes from MAX with 11 channels in MAX! The channels in MAX are named in MAX as voltage_0 thru voltage_10 and this should be what pops up in the dialog box!  Looking at the interior code of the select signal VI gave me the impression that the list in the display needs to to stored internally into a local variable and that until this VI is run at least once the pop up display would not populate the list of MAX channels so I went and ran the VI containing the select signals VI once to populate the list from MAX.  The first time I did this some of the select signals VI (there are 6 in the VI) did show  up with the list populated as configured in MAX but not all of the select signals VIs did! And when I exit out of the project and come back the next day and do this all over again the list always start up with the default list and even when I run the VI to populate the lists the default list still shows up!  If I go back into the tool menu and select the same select signals express VI and install it on the block diagram the list always gets populated once the code is run one time!  I think that NI has some work to be done on getting this VI to work correctly