Skip to main content

Routed events in WPF let you do all sorts of crazy (and very handy) things. The fact that you can preview events on the way down the visual tree, as well as hook them as they bubble back up opens up a whole world of possibilities that would have been nothing but pain back in WinForms. But I'm not here today to wax poetic on routed events, I'm here to talk about some of the lesser known functionality of the WPF event system - namely Class Handlers.

What is a class handler? Well, it is a way of attaching to an event for an entire class, and not just a particular instance of that class. Say you want to do something special on GotFocus for every TextBox in your application. Generally, there would be two possible paths that you could follow. One, you could make your own custom TextBox that would hook into its own GotFocus event and execute your custom logic - but now you have to remember to use that custom TextBox class everywhere in your app. Or, even worse, you can go around hooking to the GotFocus event on every single individual TextBox.

With a class handler, however, you can hook into the GotFocus event for the TextBox class, i.e., every single instance of TextBox ever created in your application will get your custom logic. This is a lot cleaner than either of the two other solutions, and the technique in general puts a lot of power in your hands.

OK, let's dive in and take a look at how to use that power. Below is a screenshot of the sample app we are going to make today. Not really that much to look at - just three ListBoxes with some images and blue rectangles inside them.

Example App Screenshot
By default, when an item is focused, it fires a RequestBringIntoViewEvent. This event is handled by the first ScrollViewer along the visual tree, and that ScrollViewer will try and bring the focused item into view. This is why when you click on an item in a ScrollViewer that is only partly in view, the ScrollViewer will scroll to bring the item fully into view. This also will happen if you use the arrow keys to move between items.

In this sample app, we have turned off that functionality for any Image instance in a ListBox - clicking on or arrowing to one of the images will not cause it to scroll into view. However, the blue rectangles continue to scroll into view.

So how did we turn it off? We used a class handler, of course! Take a look at the code below:
using System.Windows;
using System.Windows.Controls;

namespace ClassHandlerExample
{
  public partial class ClassHandlerExampleWindow : Window
  {
    static ClassHandlerExampleWindow()
    {
      EventManager.RegisterClassHandler(typeof(ScrollViewer),
          FrameworkElement.RequestBringIntoViewEvent, 
          new RoutedEventHandler(HandleRequestBringIntoView));
    }

    private static void HandleRequestBringIntoView(object sender, 
      RoutedEventArgs e)
    {
      var item = e.OriginalSource as ListBoxItem;
      if(item != null && item.Content is Image)
      { e.Handled = true; }
    }

    public ClassHandlerExampleWindow()
    { InitializeComponent(); }   
  }
}
 
This is the code behind the window you saw above. First, we have a static constructor that does the actual class handler registration. The method to call is RegisterClassHandler, a static on EventManager. This call is registering the function HandleRequestBringIntoView for the event FrameworkElement.RequestBringIntoViewEvent on the ScrollViewer class.

This means that the HandleRequestBringIntoView function will fire whenever a RequestBringIntoViewEvent (that has not yet been handled) bubbles through any ScrollViewer in our application. If you wanted handled events too, there is an overload for RegisterClassHandler that takes a boolean for handling events that have already been marked as handled.

A handy thing about class handlers is that they get invoked before any instance handlers. This means that a class handler gets a chance to handle the event first, and so can keep any regular instance handlers from ever running.

It is that exact fact that we use to our advantage in this code. If the original source of the event (i.e., the element that is requesting to be brought into view) is a ListBoxItem and its content is an Image, we mark the event as handled. Otherwise, we do nothing. By marking the event as handled, the ScrollViewer never runs its own default logic, and so the image is never scrolled into view.

And there you go! Now you know all you need to know about class handlers. A word of caution, though - class handlers are extremely powerful. It is deceptively easy to break built in functionality or seriously slow down your application if you use class handlers unwisely. But hey, with great power comes great responsibility, right? If you would like to grab the source for this example, the zip file below holds the Visual Studio solution.


Source Files:

Comments

Popular posts from this blog

C# Snippet - Shuffling a Dictionary [Beginner]

Randomizing something can be a daunting task, especially with all the algorithms out there. However, sometimes you just need to shuffle things up, in a simple, yet effective manner. Today we are going to take a quick look at an easy and simple way to randomize a dictionary, which is most likely something that you may be using in a complex application. The tricky thing about ordering dictionaries is that...well they are not ordered to begin with. Typically they are a chaotic collection of key/value pairs. There is no first element or last element, just elements. This is why it is a little tricky to randomize them. Before we get started, we need to build a quick dictionary. For this tutorial, we will be doing an extremely simple string/int dictionary, but rest assured the steps we take can be used for any kind of dictionary you can come up with, no matter what object types you use. Dictionary < String , int > origin = new Dictionary < string , int >();

C# Snippet - The Many Uses Of The Using Keyword [Beginner]

What is the first thing that pops into your mind when you think of the using keyword for C#? Probably those lines that always appear at the top of C# code files - the lines that import types from other namespaces into your code. But while that is the most common use of the using keyword, it is not the only one. Today we are going to take a look at the different uses of the using keyword and what they are useful for. The Using Directive There are two main categories of use for the using keyword - as a "Using Directive" and as a "Using Statement". The lines at the top of a C# file are directives, but that is not the only place they can go. They can also go inside of a namespace block, but they have to be before any other elements declared in the namespace (i.e., you can't add a using statement after a class declaration). Namespace Importing This is by far the most common use of the keyword - it is rare that you see a C# file that does not h

C# WPF Printing Part 2 - Pagination [Intermediate]

About two weeks ago, we had a tutorial here at SOTC on the basics of printing in WPF . It covered the standard stuff, like popping the print dialog, and what you needed to do to print visuals (both created in XAML and on the fly). But really, that's barely scratching the surface - any decent printing system in pretty much any application needs to be able to do a lot more than that. So today, we are going to take one more baby step forward into the world of printing - we are going to take a look at pagination. The main class that we will need to do pagination is the DocumentPaginator . I mentioned this class very briefly in the previous tutorial, but only in the context of the printing methods on PrintDialog , PrintVisual (which we focused on last time) and PrintDocument (which we will be focusing on today). This PrintDocument function takes a DocumentPaginator to print - and this is why we need to create one. Unfortunately, making a DocumentPaginator is not as easy as