MouseOut

SRPSupport · December 2013

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

KevinFournier · December 2013

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.

SRPSupport · December 2013

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

KevinFournier · December 2013

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.

SRPSupport · December 2013

Yep that's right, thanks Kevin

User: James Birnie

AusMarkB · December 2013

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

KevinFournier · February 2014

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.

SRPSupport · May 2014

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

SRPSupport · July 2014

Hey James,

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

SRPSupport · July 2014

Hey Mark

My pleasure.

User: James Birnie

MouseOut

Comments