Some weeks ago I wrote a blog item about how to get the functionality of PerformClick in WPF.
I remember thinking at the time that it was a fairly clunky workaround and wondered why PerformClick hadn't been included in WPF. Of course there may be lots of reasons, beginning with 'No-one thought of it' and ending with 'It was just too difficult'.
But while looking at an apparently unrelated problem this week, it occurred to me that maybe there is a more elegant solution staring me in the face - WPF's Commands.
In many cases where PerformClick is required, the situation is that whatever action is wired up to the Button's Click event is often also of interest to other controls - perhaps a menu item, a keyboard shortcut or a user instigated selection of some kind or other elsewhere.
WPF Commands, if this is a new area for you, is a variation on the theme of Events. Whereas events are generally locked in to a specific action, a Command on the other hand is more along the lines of a loosely-coupled task that can be subscribed to from several places.
Of course,you may be sat there thinking that it doesn't take a coding genius to create code for events that can be re-used and accessed from several different points. The point is though that Commands are specifically designed for this purpose and they have a feature that I think makes them almost unique. (Can you be 'almost' unique, the literary critic part of my brain asks? Never mind, you know what I mean!)
Commands have the ability to turn themselves off in situations where it wouldn't be appropriate for them to be available - and back on again when it is. A common example is the Paste Command, where it doesn't make sense to have it available unless there is some data in the Clipboard.
Similarly, you might build in a test where the Exit command isn't allowed to function unless the user has taken some action, such as saving data. There are lots of similar examples.
WPF comes with a bundle of pre-built Commands for common tasks, including Copy, Cut, Paste, Find, Save, Close, Play, Zoom, Align and many more. Naturally, the designers of WPF don't know the exact actions you will want to link to each of the commands in every circumstance, so there is still some work for you to do. Commands are clever - but they're not magic!
Apart from the built in Commands, and on the basis that there are never enough of these kind of things, you can create Commands of your own relatively easily. You can set the bindings and the rules that decide when it may be able to execute and when not (as per the Paste example earlier).
All of which brings me back to my original thought. If you can create a Command that both a Button and (in the case of the Forum question that got me thinking about this) a Menu Item can bind to, then that really removes the need to worry about PerformClick. Command would be a neater and more sophisticated way of achieving the same effect.
If you want more info on Commands, here is a useful link to an MSDN Introduction to Commands article.