YET ANOTHER UPDATE: I received confirmation from Joe Stegman that yes, this is indeed a bug in Silverlight 2 Beta 1 but has been fixed in the forthcoming Beta 2.
ANOTHER UPDATE: I found what is causing this, you can read about the exact cause and download sample code in a newer post. If this is a bug in Silverlight or if there is a nuance with the TextBlock of which I'm not aware has yet to be determined.
UPDATE: This is most likely NOT a bug in Silverlight itself but probably has something to do with how I am implementing it. I will post a detailed description of what caused it and how to avoid it as soon as the cause is identified.
Let me start by saying that this issue is one that I doubt will be seen by many people, even if it does persist into the RTM version. Even describing this issue without using lots of pictures (or better yet a (mal)functioning sample) is not an easy task, so let me see how well I do.
As I said in a previous post, I started a CodePlex project to build a session scheduler in Silverlight. Within this application there is a User Control defined that represents a single session which includes the information about the session, the graphical representation of that data and an animation. When the app reads in data from an XML file it creates a number of instances of this user control in specific locations in a Grid.
Matt Casto joined the project this week and the first thing he did was to create a more elegant way to catch the MouseEnter, MouseLeave and MouseLeftButtonDown events by adding them to the user control declaration tag instead of to the transparent rectangle that I had been using previously. This made for a nicer experience as the area that handled the events would expand with the control during the animation.
From the picture above you can see what the animation looks like in it's final (open) state. When in this state, there is a path that overlaps a section of another instance of the user control below the currently active one. With the new behavior if you move the mouse into this path covered area of the active user control, nothing happens since the mouse is still within the defined area of the user control. So far this is all good.
The problem arises when you have one instance of the user control in an open state, then move the mouse into the area of another instance of the user control that would be covered by the expanded path. The area I'm talking about is the top/left part of the small version of the control.
The result is that if ANY animation is in it's open state, the instance of the User Control that would be covering that section is activated, not the instance of the control that the mouse is actually over.
I've reported this issue to Joe Stegman and may also post it to the forums at silverlight.net. If I hear from Joe or someone else that it's actually a problem with our code and not a real Silverlight 2 bug, I'll gladly update this post with that information.
This one is most likely a rare issue that will not effect the vast majority of Silverlight applications, but it does appear to be a real issue. For our application we decided that we can live with the odd behavior but for a business application that would be a hard case to make.