LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea
The venerable Array Size function should just resize itself for the number of dimensions on the input array and have each dimension's size emitted with a separate scalar output.

Having the possibility to hide a pane at run time. For example if you want to hide a Button Palette, a status bar, Tree View or helper pane as specified in this snapshot:

 

 HidePane

Message Edited by Support on 06-02-2009 12:35 PM

Dany (below) requested support for alpha channel in picture control (I strongly agree with that). I also want support for drawing antialiased object (line, rectangle, circle, arc, ...).

Additionally, improve the performance of the picture control rendering will be greatly appreciated.

 

PJM

Sometimes I like to have the Context Help window viewable to my users so they can hover over FP elements and get some quick pointers on their respective functionalities.  I'd like to be able to control the position and size of the window, and also choose programmatically when it's floating/not floating, so I can have it blend into my user interface more intuatively.  It'd be great to be able to embed it into a subpanel too.

This goes a bit with Christian's suggestion to separate edit time and run time front panel sizes.

 

While I do appreciate the alignment grid on the front panel I find it insufficient a lot of the times. What I would like to see is some alignment helpers similar to the ones that are provided in the form editor of MS Visual Studio:

 

  • When you move a control close to another control, it automatically displays a standard distance "helper" that you can snap to.
  • When you move the edge of one control close to the edge (in one dimension) of another control a vertical or horizontal line is drawn from that other control to which you can snap, regardless of whether it happens to sit on a grid line or not. 
  • When you move a control close to the edge of the front panel a standard distance "helper" is displayed that you can snap to.


All of these features should be available for a move as well as for a resize of the controls.

 

You can find screen shots of what I am talking about here and here.

Add support to transparency in picture control. When you load a PNG file to the picture control consider the Alpha Channel instead of a threshold.

A pop-up that appears when a user hovers over a buffer allocation dot would be very useful.

 

Data to display:

1) size of allocation in bytes

2) expected longevity (freed when vi quits vs. USR)

3) frequency of allocation (once at first run, each loop, etc.)

 

I know some of the data can only be a best guess but whatever additional data we can get

will be an improvement, especially when dealing with large data sets.

 

Thanks.

 

Matt

When we read the "cursor index" property of a cursor from an intensity graph, we only get a single number. This is insufficient and inconsistent.

 

Since the graph data is a 2D array, we should get an array with two elements, one for the x-index and one for the y-index. Two indices are required to translate the cursor position to the corresponding array element.

 

(This change would make it more consistent. Have a look at the output of e.g. "array size" and "array min&Max" when the input is a 2D array. Same thing!)

Since very early LabVIEW versions, we always had the small sizing tip strip at the bottom that showed the current size in pixels when resizing an object on the front panel or diagram.

 

This is maybe OK for simple decorations, but for most other objects it is very inadequate and not helpful at all. For example if I resize an "index array" node to show more outputs, the node size in pixels is probably the least interesting information! It would be much more useful to indicate the number of outputs instead.

 

Now if we resize an "index array" node for 8 outputs, we simply resize until the tip strip shows [8 outputs]. Without this, we need to guess the size, count, resize again, etc. A slow, tedious, and error prone process, especially for larger sizes.

 

Of course the "resize tip strip" should adapt depending on the object that is being resized to always show the most useful values(s). Here are some possible examples:

 

 

Resizing action                      example of tip strip


 

Resize a 1D array:                  [5 elements visible]

Resize a 2D array:                  [6 rows x 5 columns]

Resize "built array" node:          [7 inputs]

Resize "index array" node:          [5 outputs] 

Resize "initialize array" node:     [3 dimensions]

Resize "replace array subset" node: [8 elements/subarrays]

Resize "compound arithmetic" node:  [4 inputs]

Resize a graph:                     [Overall size: 400x600, plot area: 380x500]

...

...

 

It should of course apply equally for front panel and diagram objects. For example the suggestion for the arrays would apply to an array control, array indicator, or array diagram constants. 

 

Of course there are many more possible objects, each with it's on set of useful size parameters. This is just a small collection. Please go over the palettes and make other suggestions!

 

 

Message Edited by Support on 06-02-2009 12:36 PM