Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

MouseOut

Hi team

Thanks for adding the OnMouseExit event! Unfortunately it seems to work a little too well for me...

I dynamically create button controls within the panel according to the panel's size. These panels expand/collapse as needed and I was wanting to collapse them again when the user left the relevant panel control. However when moving between the button controls on the panel (which are owned by the panel and have a 1 pixel gap between them), it sometimes fires an OnMouseExit event, even though I am technically still within the panels bounds.

I tried adding the following code within the OnMouseExit event for each panel which works ~85% of the time. I can live with this, but I was wondering if the above behaviour is expected, or if someone had a better idea maybe...?

Assuming this behaviour is expected, another option could be to enhance the OnMouseExit event to include the current mouse position within the control via param1, param2 etc perhaps?

Thanks,
James
// check if the current mouse position is still within the bounds of this control check_cursor_pos_vs_control: withinBounds = true$ * get mouse position versus the focused control mousePos = Blank_Struct('POINT') GetCursorPos(mousePos) rv = ScreenToClient(get_property(focus, 'HANDLE'), mousePos) xyControl = Struct_To_Var(mousePos, 'POINT') * test if we have left the control xPosVsControl = xyControl<1> yPosVsControl = xyControl<2> if xPosVsControl < 0 or yPosVsControl < 0 then withinBounds = false$ end else controlSize = get_property(focus, 'SIZE') controlWidth = controlSize<3> controlHeight = controlSize<4> if xPosVsControl >= controlWidth or yPosVsControl >= controlHeight then withinBounds = false$ end end if not(withinBounds) then gosub check_close_panels end return
User: James Birnie

Comments

  • Mouse exit is definitely one of this things that can give you more events than you wanted. Our MouseExit event is really just an extension of Windows' WM_MOUSELEAVE message, so yes, the overzealousness stems from Microsoft's implementation. In other words, Microsoft decided that the event would fire for any reason that the mouse might leave, even if it's because the control disappeared.

    The only possible solution I might consider a possibility is some kind of property you can call to cancel any impending exit events. Such a property would reset each time the mouse entered the control, but while the mouse is over the control setting the property would tell the control not to fire the next MouseExit event no matter what.
  • Hi Kevin

    Yeah I hear you, the behaviour MS have given to some of their messages aren't quite what I've expected in the past either. In this case, like the MouseExit event, the MouseEnter event fires multiple times also e.g. when moving between controls on the panel, so its a bit messy to use these events perfectly.

    A few months ago I wanted to trigger a custom "RESIZE" event when a user resized the main form. But I only wanted it to fire if the actual size of the form changed (e.g. not when they just moved it). Then I realised I also had to catch the maximise and double-click on the titlebar messages (which unfortunately didn't fire a maximise message). So I learnt that just doing it yourself can be the best way to keep it efficient and basically "get it right" sometimes.

    Cheers,
    JB

    User: James Birnie
  • I see. I better understand your situation now. The issue is that the Panel's event fires an exit event even when you hover over one of it's children. Yes. this is MS behavior, but it might be something I can mitigate. I'll add it to my to-do list and see what I can do.

    I thought you were having issues with a child control, not the panel itself.
  • Yep that's right, thanks Kevin

    User: James Birnie
  • Because James and I are doing much the same thing here, I have the same issue but here's my added symptom for reference.
    I find that sometimes the speed in which you move the mouse also affects whether or not the event is fired.
    This then leaves me sometimes with the mouseexit code not occurring when I genuinely leave the panel but then appearing to occur when I re-enter the panel. I assume the latter is because I enter the panel and then immediately mouseover one of the child controls so considering the above, it is the mouseexit but it doesn't appear so to the user.

    To the user it looks like this:
    Some mechanism resizes the panel so that it is larger and more controls are visible. Moving the mouse outside of the panel's bounds should and often does resize the panel to its smaller version. Sometimes however, the panel remains at the larger size so the user drags the mouse back over the large panel but as they do, it then resizes to the smaller version and the user looks like this
  • Please download a beta build of either SRPControls.ocx if you have a Pro license or SRPPanel.ocx. Let me know if it fixes your MouseEnter/Exit woes.
  • Hi Kevin

    Thanks for this, sorry for taking so long to upgrade (we are on SRPControls3.1.1 now). I tested this functionality and it still calls MouseOut when within the panel for me, when the end-user ends up on a cell between SRP Buttons within the panel. So I still need my defensive code listed above (which is no big deal).

    User: James Birnie
  • Hey James,

    I'm a bit slow on this one but thanks for the code post.
    That seems to work for me too.
  • Hey Mark

    My pleasure.

    User: James Birnie
Sign In or Register to comment.