Scott Hanselman

MouseEnter and MouseLeave loops in WPF

January 12, '09 Comments [20] Posted in Windows Client | WPF
Sponsored By

Sorry for the cheesy blur effect, but my buddy hasn't gotten permission from the company he's working with to blog about his project yet. When we get permission I'll blog in more detail about all the fun stuff we've learned.

I'm helping a friend of mine occasionally with WPF-related questions as he works on a really good looking application that features clothing from a large US apparel manufacturer. There's a nice animation as you roll over transparent PNGs of two shirts. The shirt you're rolling over zooms to the forefront with a nice blur and zoom animation. Below the shirts is a styled Radio Button with "Mens" and "Womens" text.

There's MouseEnter and MouseLeave events hooked up

We found ourselves in a really strange situation where there was a tiny strip of pixels that, when moused over, caused an apparently Enter/Leave loop.

The screenshot below shows the System.Diagnostics.Debug.WriteLine() calls showing the output from the application. Notice that the mouse is just approaching the second men's shirt. At this point the application would freak out as it got stuck in a loop until I moved the mouse away.

image 

This was really confusing and my knee-jerk reaction was that was somehow a bug in WPF, but then I remembered something an engineer smarted than I said:

"My code runs exactly as I wrote it."

If I go on the assumption that I haven't found a major bug in WPF, then the problem must be me. The code must be running as I wrote it.

It turns out that if you change the element that is underneath the mouse, like hiding it or changing its Z-order, you'll get a MouseLeave for the changed element and a MouseEnter for the new element that appears.

We'd gotten ourselves in a loop because we'd pushed the elements so close to together that they overlapped. One element would leave, the one underneath would popin, and the swapping would continue.

The solution was as simple as zooming in on the XAML view in the designer and moving the elements away from each other so they didn't overlap.

It was such a frustrating bug and we fought with this for an hour before we stepped back and reminded ourselves that it might just be the way we wrote it.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Monday, January 12, 2009 9:38:04 AM UTC
Seems like you might want to add debug-mode code which walks through your images and checks for overlaps, otherwise this is a horrible little trap waiting for every minor change in layout or graphics...

Will Dean
Monday, January 12, 2009 1:22:44 PM UTC
Reading your post sounds so familiar. My team is in charge of the Application Framework which the Application developers use to develop the company's product. Whenever something goes wrong the first reaction from the application developers is to blame the FW even if it isn't the FW. Whenever my WPF stuff doesn't work I accept I made some mistake, but it seems when you have access to WPF team, the first reaction is to verify that WPF works much like the application developers needs verification that the application framework works.
Marthinus
Monday, January 12, 2009 1:32:44 PM UTC
It reminded me of something you'll see on some websites (and I might have been guilty of the bug one or twice myself), where the text you mouse over expands with a bounding box smaller then the bounding box that determines if you've left the text and it should shrink again.
What happens is that the text will flicker large and small if you're over a small 'gray' area.
Monday, January 12, 2009 1:57:50 PM UTC
@Will
...familiar to many that have tried relatively complex programming/interactivity in Flash.

Flash and Silverlight (and most web programming, really) blurs the line between programming and desktop publishing, so you get the fun problems of both, plus the new problems when the two overlap (pun intended).
tb
Monday, January 12, 2009 2:40:54 PM UTC
To be fair though, your code will run exactly as you wrote it only about 99.99999% of the time.

The rest of the time, it's .NET's fault.
jtradke
Monday, January 12, 2009 5:01:55 PM UTC
ok this has nothing to do with this topic but I can't get it out of my head unless I share it with someone if not the world.

Every time I see this topic in my feed list I keep wanted to AND DO read it as "Two Mouse enters One mouse leaves".

Anyone else?
Wednesday, January 14, 2009 10:55:32 AM UTC
I met a proplem which is similar to this.
I put a clip into a Grid. And drag another clip, when i draged over the edge of the previous clip, i received DragLeave event, although it's still hover on the Grid and i didn't release the MouseLeftButton. I see the event routing, but it's really bothersome. :( When multi-clips, many DragEnter and DragLeave... i have to judge if it hoverd on Grid and drop the meaningless event.

any good idea? u know, i have to release resources when DragLeave.
Yohan
Wednesday, January 14, 2009 5:10:11 PM UTC
Your friend should change the transparent of PNGs to '#00000000' (or any other except Transparent or "#00FFFFFF" ).
It should help.

If we set Transparent (or "#00FFFFFF". Transparent is "#00FFFFFF" ) we can't catch any events of mouse over this background. It is like as set HitTestVisible false.
Wednesday, January 14, 2009 5:21:12 PM UTC
Besides commands don't work for control with Transparent Background too.

Regards, RredCat.
Wednesday, January 14, 2009 6:37:12 PM UTC
That was what I suspected, XAML, WPF and SilverLight are quite shitty tools.
Flash Guy
Thursday, January 15, 2009 6:09:37 AM UTC
Seen similar behaviors with html page where css (on mouseover) would resize element causing a change in layout that would place element off mouse position. This would trigger resize and element would be back under mouse. Result was a similar dynamic loop effect you experienced.
Thursday, January 15, 2009 6:44:41 AM UTC
2Flash Guy
User plays chess with PC. PC wins three times in a row.
- Fucking Windows. It is unstable again.
Right?
Thursday, January 15, 2009 5:06:12 PM UTC
Hi,
I'd like to add one more point to check out. Some years ago we had a similar effect with a blinking tooltip. It turned out that the customer has changed one mouse cursor to an extra large size so the poping tooltip changed the cursor which changed the hotspot 1px sideways which in turn resulted in a mouse leave event that removed the tooltip window. loop.

Martin
Thursday, January 15, 2009 11:56:31 PM UTC
I ran into this problem when trying to add an Adorner within a MouseEnter handler and removing the adorner within a MouseLeave handler. The looping "bug" resulted in the Adorner being added and removed repeatedly causing a flashing appearance on the screen?

So beings the addition of an Adorner "change[s] the element that is underneath the mouse", what would be an appropriate way to add an Adorner when the mouse enters and remove it when the mouse leaves?
Kennie Davis
Friday, January 16, 2009 6:19:01 AM UTC
Kennie

U can set IsHitTestVisible = false to prevent flashing.
Yohan
Tuesday, January 20, 2009 8:50:28 PM UTC
When I teach new people about programming, I always share these two statements first:

1) The best thing about computers is that they will ALWAYS do what you tell them to do.
2) The worst thing about computer is that they will always do what YOU tell them to do.
Saturday, January 24, 2009 3:55:24 AM UTC
From my 10+ years developing experiance, programers expect a bug in the most complex/complicated portion of their code. However, in about 90% cases, it is not there.
Stan
Tuesday, January 27, 2009 5:32:52 AM UTC
@Joel. I've heard a similar sentiment before

1) The best thing about computers is that they will ALWAYS do what you tell them to do.
2) The worst thing about computer is that they will ONLY do what you tell them to do.
msfte
Wednesday, January 28, 2009 9:53:46 PM UTC
Nice Article
utsav
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.