LabVIEW Idea Exchange

Often when using tables (and multicolumn listboxes), the content of the table column or row header is longer than the desired width of the cell.  It would be nice if there was an option to make the contents of the cell wrap to the next line, similar to how tables work in Excel or Word.

Also, adding vertical justification options such as Top, Center, Bottom to the Active Cell property subset would be nice.

Here's a crude illustration of what I'm talking about.

The title says it all, for the reference this discussion on LAVA that explains how to do it using .NET :http://lavag.org/topic/9216-deletion-of-folders-and-files/

Please give us a native way to do that in LabVIEW.

The Preferred Execution System setting of a VI allows for more explicit developer control of a VI's thread allocation. Currently there is no way to quickly view which VIs have been configured for which execution system. Furthermore it's not easy to see what execution system a VI configured with 'same as caller' will run under.

This idea is to add an optional color coded representation of each execution system to the VI Hierarchy window. When enabled, each of the execution systems is highlighted with a certain color around VIs, and applied to the lines between VIs.

For VIs with an explicitly configured execution system, the color around the VI would be solid. For VIs set to 'same as caller', the color around the VI would match that of parent in the call chain, but have a different appearance (shaded diagonal colored lines in this example). For VIs which are 'same as caller', but called from multiple different execution systems, the color around the VI would be shaded black.

Full resolution example:

Spoiler

Adding this option would allow the developer to quickly view what execution systems have been configured, which ones are not is use, and potential call chains of each execution system.

Something that bugs me is when I right click on a terminal to create a Indicator, for instance, and the frames around it expands to fit the new Indicator and it's label default. This is much worse in complex diagrams with many nested frames.

I propose that the frame expansion should be done only after the text validation in order to increase the minimum necessary, as shown below:

If you attempt to write an Enum to a TDMS Property the function will return error -68007.  "This channel or property value contains a data type that is not recognized by this version of LabVIEW."  Reading and writing Enums as Channel Data however works just fine.

There are a few work arounds for writing and reading TDMS properties as Enums, attached is one such example where we write the value as a string, then have to convert that back later.  There is extra work involved because we need to generate an error if the string value doesn't exist in the enumeration provided.

This idea is to ad native Enum Reading/Writing to TDMS properties.