|
|
|
Hit
testing for complex visuals has traditionally required a lot of work from the
developer. When you have intricate imagery made up of multiple shapes, it can
be difficult to work out which item, if any, the mouse is over. This becomes
particularly complex if you have chains of transformations.
|
|
|
|
WPF does
all the work for you. All of the drawing elements automatically support hit
testing. (And if you eschew the FrameworkElement-level drawing elements, and
instead drop down to the low-level drawing API, there is still support down
there for making hit testing straightforward.)
|
|
|
|
All
elements raise events for mouse activity including button, wheel, enter, and
leave. The bubbling event model makes it easy to trap events for large chunks
of your visual tree in a single place, and yet still be able to work out
exactly which element was hit. (Events that bubble will propagate their way
from the leaves of the UI tree up to the root until they hit a handler.)
|
|
|
|
As an
example of how this works, consider a button with custom visuals. You can
make a button any shape you like, and the hit testing works perfectly, even
though the button doesn’t know much about its visuals. All it does is trap
the relevant mouse events as they bubble out of its visual tree. This means
that even the most complex of shapes will work in exactly the same way as the
basic standard rectangular button shape.
|