LabVIEW Idea Exchange

Make the Panel Resize event in the event structure a filter event.  This would allow for clean, professional looking control of VI panel size.  Use cases include: limiting the maximum panel size, preventing a panel from resizing in one direction, only allowing the panel to resize in discrete increments, etc.

In traditional windows programming, filtering the WM_RESIZE event is often used to control window size and I'd like to see this same functionality come to LabVIEW.

Ideally, this change would include a Discard? option as well as NewBnds and Act as options in the Event Filter Node.  Setting NewBnds or Act would allow the programmer to amend the resize before it takes effect.

Originally discussed here, this would be a time saver in quite a  few cases:

when dropping a structure (sequence, case, while or for loop, etc) over wires, an option should be provided allowing these wires to go through the structure (instead of ending up untouched UNDER the structure as is currently the case). Maybe with a modifier key?

Illustration:

Starting from this simple situation, where I want to do some comparison on the two strings (please imagine that the wires go through a lot of hooplahoops rather than directly to the indicators shown, as otherwise the solution is trivial):

I currently need to drop a sequence structure and do all the connection manually before creating a subVI (or doing stuff in a case structure, see below):

The suggestion is to go directly to this:

The reasons this would be useful are plenty, I think.

For instance, you want to do some sanity check on a bunch of wires now that you have added a new control on your panel. As of today, you need to drop a case structure, get wires you are interested in one at a time, connect them to the left of the structure, pass through the structure, connect them to the right of the structure, delete the wire underneath the structure, reconnect them to the right tunnels, etc...

Now, for a case structure, there might be some options on how to do that (for instance connect the wires through all cases? through the True case only?). Likewise for a while/for loop (you could autoindex at the entrance and/or at the exit, a mess that already exists anyhow).

My 2 cts.

Take for example an enum that is saved as a type def. The enum has many items (let's say words) of varying length.

In order to see all of the elements, inclusive of the widest one, the array can be sized with the right-click option "Size to Widest Element".

If the type def'd enum is edited, and a longer element is added, the array of enum constants will not size to the widest element. This can be frustrating, as dozens (or more) of these arrays scattered about the program are rendered unreadable.

If the user has previously chosen to "Size to Widest Element", this setting should persist. If the user edits the enum, all of the array constants should size to the widest element.

-------------------------- Example ----------------------------------------------------------------------

Problem: my code accesses many different properties of many different controls. I need to locate where a specific property of a particular control is read/changed.

I know that the Find panel offersi me the option of searching by text, like

but that is not the solution, because I need to type thename of the property, and because I may match many other objects with the same string (comments, other controls with the same property, etc.)

I'd like a faster way to get to where I need. For instance the contetual menu could offer Find/specific property according to where the right-click was.

Say I've got 4 U8s that I want to join into a U32 - right now, I have to build 2 of the U8s into a U16, then build the other U8s into a U16, then build the 2 U16s into a U32.  I'd like to see these primatives growable to each datatype width.

Add a module to LabVIEW to use it on Android OS or Apple iOS. 

People have already been getting smartphones for awhile.  And now in 2011, there are so many manufacturers that make tablets with Android OS or even Windows.  Apple iOS is considered to be the cool thing but Android OS is more open and used by more manufacturers (since only Apple for it's iOS).  Since the Andorid Tablet is so new, yes there are more Apple tablets out there than Android tablets but if it's like the smartphone market, Android OS will overtake the iOS market.  It's just a matter of time. 

I don't know whether one is easier to code than another, but if you had the time I think a module for both the Android OS and the Apple iOS would be extremely powerful.  Wouldn't it be great if we could run an instrument from our phones or tablets?!?! 

But I would just be careful to make sure the module was robust and not too many key features were missing from the full LabVIEW version.  In the past, we tried the PDA Module and Touch Panel Module for an instrument and it didn't work out.  The module was very buggy and missing a lot of features from LabVIEW that we though were important key ones.  We ended up abandoning the PDA module idea and went with an advantech touch panel computer with Windows XP and just kept writing with regular LabVIEW.