LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea
 NativeLoopWait.png
If unwired it would default to 0, and at least let thread switching occur.  You could maybe right click on the loop and remove the wait node to make it run as fast as possible (like it is now), but it should be there by default...  Maybe also right-click on it and get to choose between "Wait (ms)" and "Wait until Next ma Multiple"?
  
(PS: I know that you can do this using timed loops, but I'd like to see it in all of them - I've seen too many "programmers" complain that their CPU is at 100% because their loops are going nuts).

By default, the mouse scroll wheel scrolls the block diagram or front panel vertically, CTRL+SCROLL scrolls through cases/events/sequences and adding the SHIFT modifer to either accelerates the scroll. In order to scroll horizontally, however, the mouse has to be hovering over the horizontal scrollbar. Because of the predominant left-to-right, top-to-bottom style of diagram organization, it would be excellent to have a more accessible way to scroll horizontally.

 

I haven't found anywhere ALT+SCROLL is used - I think horizontal scrolling is a good candidate to fill that spot.

 

 

Having a native polymorphic PlusAndMinus function would clean up so many of my diagrams.  Anything where you are programmatically resizing and centering front panel objects or objects in the picture control toolkit would benefit the most, but there are plenty of other uses.

 PlusAndMinus.png

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