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.

Consider how CTRL+E toggles between the BD and FP, back and forth. Likewise, it would be nice if CTRL+Shift+E toggled between the VI and its corresponding Project Item.

Currently, when viewing a VI window, CTRL+Shift+E will highlight the Project Item -- but this action is unidirectional -- pressing the same key combo again does not take you back to the VI (it just does nothing).

Oh, and, Reflexive... is that the right word? Bidirectionality? You get the drift. Here's an illustration:

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.

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:

Here's a dumb mistake I think many of us can relate to:

It would be really nice if the VI were just broken in this situation. But I can understand why it's not necessarily simple to mark node *outputs* as required.

But maybe there could be a way for the editor to *hint* that there is a problem here. Maybe the bundle nodes could change color when the output terminal is wired, so you could get a little more obvious feedback if you screwed up like this.  The same could go for any other primitives that have a "for type" input (e.g. unflatten from string, variant to data, to more specific class, etc).

Granted, VI Analyzer could report bugs like this, but having a little more immediate feedback would probably be a big win.

(Let me know if this should be cross-posted to the NXG idea exchange, too).

Did you know you can make property nodes and invoke nodes smaller by not showing the names?

Well, forget you know, it's a terrible idea to hide that information! You lose the self-documentating nature of LabVIEW. I use this as a comparison for Call Library Function Nodes (CLFN) - by default, these are dropped on the block diagram without showing names. I propose that the default is to show names for CLFNs for the sake of documentation, and so you don't have to hover over each terminal to find the one you're looking for. The biggest perk is simply the name of the function on the banner of the node. YES, there is a tradeoff between BD real estate and documentation, but I think "Names" trumps space virtually all the time.

The database toolkit is limted by the database variant to data function. It can only cast to a labview datatype as long as you wire that datatype to the type input. This means that you have to know the datatype of any SQL query in advance (or convert to string). It would be very useful if the function would also accept a variant datatype. This way it would be possible to cast any complex type into labview datatype, without the need of a predefined cluster.

Image - casting the database input with a the variant type input (circled) doesn't work

                                              With only 2 subdiagram, the Disable structure should behave in all cases like a flip-flop.

                                                                                        it's not currently the case and it's annoying

The Tree- Control and the Multicolumn Listbox support the presentation of a Symbols per row. But there are a lot of cases where there is needed more than one symbol per row. One very common scenario is the display of various states (Calculation completed: Checkmark; Results written to file: Checkmark; Assigned Application to open file: App-Icon...). NI does this already in the "Example Finder" window, so it is obvious there is a need for this feature.

I think it is a good practice to hold a pool of symbols, attached to the control, like NI does currently with the Trees and MCLBs. And for performance reasons there could still be the possibility to determine the columns to be capable to display symbols.

So from the LabVIEW programmers point of view there could be added the following properties / methods:

• Symbol-Displayable Colums (property, read/write), (1D Array I32): Gets or Sets the indices of colums, which can show symbols and reserve space when the property "Visible Items->Symbols Visible" is set to true
• Active Symbol- Column (property, read/write), (I32): Gets or Sets the Column-No which has focus for the next "Item Symbols"-property operation.
• Set Column- Symbols (method, takes an I32 as Index for the Column, takes a 1D-Array of  I32 as Symbol-pool indices): shortcut for setting the Property "Active Symbol- Column" followed by setting the Property "Item Symbols".
• Get Column- Symbols (method, takes an I32 as Index for the Column, returns a 1D-Array of  I32 as Symbol-pool indices): shortcut for setting the Property "Active Symbol- Column" followed by reading the Property "Item Symbols".

This should provide compatibility to the current handling of symbols since the property "Symbol-Displayable Colums" defaults to [0], so if "Item Symbols" is read or written to, it is meant to use the first column, which is status quo.