Panel resize event - can I filter events?

[Michael Aivaliotis]

I love the panel resize event, however what happens if you have a slow routine that runs in response to this event? Every single pixel increment of the panel resize fires an event. Is there a way to filter out and ignore all the intermeadiate panel sizes and only acknowledge the last panel size?

[Michael Aivaliotis]

A bit of head scratching and some head banging later, I figured it out. The solution is quite simple actually. Lucky for us, the last event which occures after you the mouse is up, is registered and shows as being equal to previous. This will do exactly what I want. Some extra checking is required to trap maximize and restore sizes, but overall is a robust solution.

[Ravi Beniwal]

Hi Michael,

This is neat. I wish it worked for pane resize too.

[Ravi Beniwal]

It doesn't work for panel resize for an XControl facade VI either, when I resize an XControl on another VIs FP. The facade VI didn't get that last panel resize event, for which old and new bounds are supposed to be the same.

[Ravi Beniwal]

It certainly doesn't work for an XControl in a VI that is inside a subpanel .

In my particular case, I had a child window of the main application, which had a SubPanel, which in turn hosted a VI with an XControl.

The Xcontrol had multiple panes and had a color ramp in one of them. Since a color ramp (z-scale) doesn't resize with panel (only the color box part does), I had to resize the color ramp height on pane resize. Now every time you resize any component in this chain, it produces a million pane resize events and you see the color ramp resizing animation for a while after you are done resizing. This issue made me search for the topic and I landed on this page.

After failing to catch the "ending only" of the resize operation at the XControl level and the SubPanel, I have resorted to catching this event in the child window and then pass the message through the VI in the subpanel to the XControl. Not an elegant solution, but it works.

[Thomas_xyz]

Hello,

I liked the code too, made a SubVI from it (LabVIEW 12):

Panel Resize Actions has ended.vi

Edited September 13, 2013 by Thomas_xyz

[Thoric]

Note that in LV2013 you can flush events. Although I haven't used it yet, I'm pretty sure this means you can flush the event queue of any further resize events. Special care may need to be taken to ensure you get the current resized dimensions when handling the event though.

[hooovahh]

Note that in LV2013 you can flush events. Although I haven't used it yet, I'm pretty sure this means you can flush the event queue of any further resize events. Special care may need to be taken to ensure you get the current resized dimensions when handling the event though.

An easier thing to do (in 2013 only of course) is you can set the size of the queue that is used for an event.  So in this case you would set the queue size to 1, and only one event will be in the queue to be handled.  In the Edit Events window select the "Limit Maximum instances of this event in the event queue" and choose 1.  My tests show that this seems to work correctly and the last event to handle is the last event fired.

[Michael Aivaliotis]

Wow, someone revived this thread. Hey, we only had to wait 10 years for a built-in solution... Sheesh.

[hooovahh]

I've wanted a scroll wheel mouse event since the event structure existed (7.0? 6.1?).  NI some times takes time catching up with implementing out futuristic ideas.  At least they give you the tools to be able to come up with your own solutions/work arounds until it is a native feature.

[Rainer Langlitz]

Okay, NI has changed this event to fire only once when the mouse button is released. But they have messed up the bounds: In LV2016 OldBounds and NewBounds always show the new bounds. If I want to know whether the front panel has been enlarged or reduced I need some code to remember the old bounds. This looks like a bug, or did I miss something?

[hooovahh]

I would say it is a bug if it is reproducible, but it seems to behave the way I'd expect in the VI I made.  Are you saying the Panel Resize event always has Old Bound and New Bounds equal?  Cause the attached VI shows that they are not always equal and events are being fired as the VI is resized, not just when the mouse is released (which is how I would want it)  This is the same for a Pane Resize as well.

Resize Test.vi

EDIT:  Oh I see what you might mean.  The last event generated will be on the mouse up, and when that happens both bounds are equal.  I wouldn't call this a bug, just odd that the mouse up generates a resize event.  Other resize events still get generated as expected.