Make the "Panel Resize" event a filter event

[TheyCallMeTim]

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.

[Mads]

Limiting resizing to one direction is something I would like to see as an option under VI properties, but a filter event would be nice for lots of other cases.

[elset191]

This would've helped me here, where I needed to resize things on the front panel before the resize event actually happened, not after because of a 'feature' of the intensity graph.

[crelf]

by Mads on 03-24-2011 04:42 AM

Limiting resizing to one direction is something I would like to see as an option under VI properties, but a filter event would be nice for lots of other cases.

Agreed.

[altenbach]

I am a bit unclear on how this should work. It is easy to "discard?" a key press or mouse click, but how is a resize operation supposed to be filtered?

We cannot discard until the resize actually happened. So, should it snap back to the original size once we release the mouse if we discard the event? This could be very annoying.

Resizing is an interactive function, so it could possibly queue up hundreds of incremental resize events and we run into a bottleneck if the front panel redraw is complicated.

[TheyCallMeTim]

The whole idea of this being a filter event is to allow changes to the resize parameters before they happen.

My vision for this change is that the 'Panel Resize' event would be called as part of processing the windows WM_SIZE event (or the equivalent OS specific event).  The WM_SIZE event is received before any action is taken on a resize (no motion occurs).  If the user takes no action on the event and lets it continue then normal resizing occurs.  If the user modifies the WM_SIZE event (for instance, changing the NewBnds) then the resize occurs to that size.  If the user discards the event (equivalent to informing the OS that the user is handling the event) then no movement takes place. 

I agree, you may/will get a lot of these -- like a mouse move event, you will get one for every move of the mouse.  I wouldn't suggest loading a file in this event case .  But, if all you do is check the bounds of the resize and then modify NewBnds or discard the event, I think it would work.

[Krish_G]

Suppose if the requirement is that the front panel should be resized to specific size.  When user presses maximize button on the tilte bar, even before the below code executes, the OS will maximize the front panel and later LabVIEW will resize it to the mentioned size.

So there will be flicker on the screen. To avoid this "Panel Resize" event with a Filter is much helpful. 

[Mads]

Now (LV2014) that the event structure has an option to limit the event queue size some people might think that this idea is already covered, but it is not.

The problem is that even if you limit the resize event case to handle just the latest event, the window will still resize independently of the execution of the resize event case. So, if for example you put code in the resize event to center a control on a pane, the control will not always move synchronously with the window/pane, but sometimes stay put a noticeable period.

The preferred solution to this would be to have a different scaling method that handles the scaling properly in the background without any coding (anchoring for example, as suggested here), but a filter event would at least allow us the ability to create the desired effect.