Jump to content
Michael Aivaliotis

Panel resize event - can I filter events?

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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.

post-15-1073111495.gif?width=400

  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

post-9308-0-73253200-1304718675_thumb.pn

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.