LabVIEW Idea Exchange

Hi 

when using the shared variable multiple variable editor to bind shared variables between the PC and cRIO its an annoying UI experience when doing more than a couple of bindings.

While the dialog can be resized, the new size is not remembered when binding the next variable, and its current size / layout is not useful for showing trees.

Also it doesn't remember your last position in the tree - so every time you wish to bind a variable you have to click to expand cRIO, click Chassis, scroll and click Module then scroll and find the variable by luck as you can only see the first few characters then click again. 

Cheers

INTRODUCTION

Dealing with arrays that are passed by reference (using control RefNums) to a SubVI has much more utility if it is NOT necessary to extract a local copy of the array in order to play with it. In additiion, there are some properties missing from arrays and clusters that would make it much easier to write code, and which seem to be consistent with other objects' property offerings.

Note: All proposed properties are IN ADDITION to existing properties. The behavior of existing properties is NOT changed.

NEW PROPERTIES

The following is a list of the proposed new properties:

NEW ARRAY PROPERTIES

ArraySize

ElemIndex

ElemRef

ElemRefs[]

NEW CLUSTER PROPERTIES

ControlLabels[]

DISCUSSION

Array Sizing 

CURRENT:       If you pass an array reference to a SubVI and want to know the size of the array, you need the wire the array "Value" property to the reference (which allocates space

                         and creates a local copy of the array) so that you can then wire the array to ArraySize to find the number of elements in the array.

PROPOSED:    I propose a new array property "ArraySize"  to return the number of elements in the array. This would have identical functionality as ArraySize.vi, but would be implemented

                         as a property where it can be used with array RefNums.

Deriving References to Array Elements

CURRENT:       If you want to traverse an array and generate a list of references to all elements in the array, you have to first set the "NumCols" and "NumRows" to 1, and then use IndexVals

                          (to set which element is indexed) followed by "ArrElem" to actually get the reference.

PROPOSED:   It'd be a lot sweeter if two more properties were added to arrays; the first would (obviously!) be an index function that is NOT related to the visibility properties of the array (as is

                        "IndexVals"). Let's call this new property "ElemIndex". Of course, in order not to break existing code, you cannot let the "ElemIndex" property cause damage to programs that currently

                         use "IndexVals", so we also need a new property (let's call this one "ElemRef") that returns the reference to the element in place of "ArrElem".

Obtaining References to Multiple Array Elements

CURRENT:     Currently the "ArrElem" property returns a reference to a single element.  it would be nice to get an array of references to elements in an array in the same manner as you can get

                        an array of references to all controls in a cluster using the cluster "Controls[]" property.

PROPOSED:  So let's create another array property called "ElemRefs[]" that returns an array containing a reference to each element in the array.

Identifying Cluster Members Obtained Using "Controls[]"

CURRENT:    The "Controls[]" property of clusters suffers from the problem that you have to know the order of elements in the cluster if you are looking for a specific cluster member. If you write

                      code using "Controls[]" then you are dependent on the order of elements in the cluster. When the cluster is a strictly typed control, this defeats the advantages of strict typing. The

                      effect is that when you change the type definition of a strictly typed cluster so that either (1) the order of elements change, or (2) you insert or delete an element, you have to rewrite

                      code that used the "Controls[]" property if that code needed to identify specific cluster elements and not just process all elements identically.

PROPOSED: A new property,  "ControlLabels[]", alleviates this problem and adds significant utility to clusters, especially those strictly typed. The ControlLabels[] property when added to clusters

                      allows the references returned by the "Controls[]" property to be matched to a specific cluster element using that cluster element's label. The ControlLabels[]  array returned would

                      be the labels of all cluster elements in the same order as the references returned by the "Controls[]" property (which is in the same order you see with "Reorder Controls in Cluster") .

                      This means that code written for a type defined cluster will still work if the type definition is modified either in the order of controls in the cluster, or if new elements are added or deleted

                      (so long as the deleted element wasn't one that was handled specifically in the code!).

Hello,

when you want to create a constant cluster using the context menu item "Create constant", the new constant is created by default in "Big", not iconified.

This can cause problem if the constant creation takes place in a structure ... because the structure is then automatically resized.

It should be nice to use the new LV2010 feature which allows to transform a cluster in an iconified way.

Manu.

Wish there was an “inspection window” showing the block diagram of a sub-vi on mouse-over. (double-click & open to edit). Perhaps, it can even appear below context help.

(Not sure if someone has already suggested it)