Program With .NET

Let’s say you start an application and a login window pops up asking you for your username and password. Once you enter your name and password, you might reflexively hit Enter and hope to be on your way.

There is an expected behavior with modal windows in client applications. Whether its a login window, a save confirmation, or an error notification, users expect the Enter button to perform some sort of action and close the window. Along with that, it is expected that the Escape key should close the window without performing any action.

Default Actions in Client Applications

In Windows Forms development, there was the AcceptButton and CancelButton properties on the Form class. You’d set these properties to the actual button controls in the Form’s children, and the Form would change it’s behavior. Likewise, WPF has something like this, albeit at bit different. In WPF buttons have the IsDefault and IsCancel boolean properties. Setting this property to True changed the Window’s behavior accordingly.

However, Silverlight’s paired down framework doesn’t include these properties or anything like them. Silverlight does have the ChildWindow class, but it doesn’t have any functionality like this.

Recently I was working on a Silverlight 4 Out of Browser application that displays a Login window when it starts out of the browser. The application had several other dialogs in use other places without a problem up to this point, but it was painfully obvious on this one that I needed to implement something.

Sure, you an always handle the KeyPress or KeyUp event on the ChildWindow, but I wanted something a little more reusable than this. I also didn’t want to create a sub-classed ChildWindow or Button control because I wanted to be able to easily apply this to existing code without major modifications.

So I decided to create a behavior.

I started with a behavior class that handles the ChildWindow’s KeyUp event and look for Enter and Cancel keys. I also made AcceptButton and CancelButton dependency properties to have a reference to the buttons so the correct button’s Command when the desired key is pressed.

When the behavior is attached to a ChildWindow the KeyUp event is handled. In the event handler, if the key pressed is Key.Enter we execute the AcceptButton’s Command. Notice that I’m using ButtonBase for the AcceptButton and CancelButton dependency property’s type. This is because ButtonBase is the base class that contains the Command property. Using ButtonBase instead of Button allows us to use this behavior with HyperlinkButtons, ToggleButtons, and RepeatButtons as well.

This works pretty well, but when I was testing it on my Login window, my logins were failing. I use the Model-View-ViewModel pattern in this application, and so my controls are databound to a ViewModel class. It turned out that my failed logins were because the Password property of my LoginWindowViewModel was still blank. I was hitting the Enter key after typing in my password, but the password TextBox still had focus, so data binding never executed and my ViewModel didn’t know there was a new password! While WPF has the UpdateSourceTrigger binding property, Silverlight 4 doesn’t have an easy way to do this.

Focus, Young Grasshopper

To fix this situation, I decided to change focus to the button being activated when the key is pressed. This proved trickier than I thought it would – just calling Focus() on the button then moving on was causing the command to execute before data binding finished.

After some trial & error, I settled on dynamically handing the GotFocus event on the button, calling Focus(), and not executing the button’s command until the button actually received focus.

What About Clicks?

I was happy with this and promptly applied it to all of the ChildWindow classes in my application. A day or so later I ran across a dialog window that wasn’t doing anything when I hit Enter. What the heck? Oh … it turns out that this window doesn’t have an associated ViewModel so it handles the Click event of the buttons instead of using Commands. Fixing this should be as simple as raising the Click event on the button, right? Well, not exactly. You can’t actually raise an event of another class like that. Also, there appeared to be limitations in Silverlight that made it so you can’t use reflection to raise events on classes. I was about to give up on this and then I remembered the UI automation support in Silverlight. This functionality was added to improve accessibility in Silverlight, but also was useful for UI testing. Turns out it was useful for me here too.

The ButtonAutomationPeer class lets you call Invoke to "invoke" the Click event on a button. There’s also an abstract ButtonBaseAutomationPeer class, but in order to use it you need to check the type of the button, and return the correct sub-class – ButtonAutomationPeer, HyperlinkButtonAutomationPeer, RepeatButtonAutomationPeer, or ToggleButtonAutomationPeer.

Final Product

At this point I’m very pleased with this behavior. I can easily apply it to a ChildWindow like this …

Here’s the final behavior class that I’m currently using.

Gotchas

Keep in mind that if your button’s Command or Click event tries to do something that requires user action, like close the application or access the webcam, you’ll get a SecurityException thrown. This is because of Silverlight’s sandboxed environment. There’s really no way around this except to keep it in mind and not use the behavior if you need functionality like this.

Also, there are a few things that this behavior doesn’t do that Windows Forms and WPF functionality does do. In Windows Forms and WPF the default/accept button has a different style that makes it apparent to the user what the default button is. This behavior could definitely be improved to apply a style change on the Accept button, but I didn’t take it that far.

Also, in WPF and Windows Forms if the Default button doesn’t close the window you’ll notice focus doesn’t actually change. I don’t know why you’d ever have a situation like this, but its possible. Just like the above situation, if you need your application to work this way you should probably just avoid using this behavior.