In [url=https://coderanch.com/t/677940/visual-basic/WPF-button-appearance-change-pressed]an earlier post[/url], I ventured an answer to the question, "How can I make a WPF button appearance change when pressed?" My answer worked, but it also exposed the daunting nature of what's under the hood for a Windows Presentation Foundation application. A mere button requires dozens of lines of XAML code to describe and, to modify the description, one must know at least a little something about how to write XAML code.
From what I've read, the virtue of this approach is that it allows the form of a WPF control to be decoupled from its function. You can make it look however you want it to look, and it will still operate the same way. We can use that to change how a WPF Button behaves when clicked, beyond just setting its color.
Back in the early days of Windows, a button appeared to move in three dimensions when pressed. By redrawing the button slightly to the right and downward, it actually seemed not to be moving horizontally or vertically, but rather in the [i]depth [/i]dimension. (Whether that means I should have said, "a button appeared to move in two dimensions," or even "a button appeared to move in one dimension," I will let others decide.) XAML does make it easy for us to add that behavior to a WPF Button. Here, again, but with slight modification, is the XAML code for our Button:
[code=xml]
[/code]
Notice three changes that are similar to what we did before: at Lines 17, 19, and 21, we've set the background color of the Button to be various shades of gray. 0xDDDDDD when it's just sitting there, untouched. 0xEEEEEE when the mouse hovers over it, and 0xCCCCCC when pressed. That's going to do more or less what we did before, but in a way that is more consistent with the darkening of a physical push-button when it recedes into its bezel or other container. But, for that old-school, seems-to-really-move, effect, we made another change at Line 38, and we inserted a new Line 52.
At Line 38, we've explicitly declared the border thickness to be two pixels, at the top, left, right, and bottom of the enclosing Border that sets the outer boundary of the Button.
At Line 52, when the "IsPressed" property becoming true fires a Trigger, we set the border thickness to be three pixels at the top and left sides, but only one pixel at the right and bottom sides. The outer boundary doesn't change, nor does the size, nor the shape, of the interior area where the Button's contents are drawn. But that interior area does get [i]moved [/i]by these new values. Let's try it.
Here's the button when it's just sitting on its own:
[img]http://exlumina.com/greyButton.png[/img]
Here's the button when the mouse is hovering over it:
[img]http://exlumina.com/greyButtonHover.png[/img]
And [i]here's[/i] the button when the left mouse button is pressed:
[img]http://exlumina.com/greyButtonPressed.png[/img]
In operation, it actually looks like the button recedes slightly into the screen, like an old Windows 3.1 button did. Notice, by the way, that it is not necessary to set the border back to two pixels when the mouse is released. The old setting of the property comes back into effect when the conditions for the trigger are no longer met. (I'll go into this in more detail in the future, after I've learned more about it.)
A question that might come up at this point is, "Why do I have to specify all that other stuff if I only want to change a couple of properties?" The answer, for whatever reason, appears to be that one cannot selectively override the settings in a style or template. One must provide all the settings that one is going to need for all circumstances. Fortunately, when we chose (in our prior example) to edit a copy of the existing template, Visual Studio simply copied the default style and template into [tt]application.xaml[/tt] for us, and allowed us to edit it from there. "What?" you may ask, "Do I have to do that [i]every[/i] time I create a new application?" No, you don't. XAML code can be kept in a "dictionary" that can be used by more than one application. More on that later.
Next, we will look into how this can work on, and solve a problem for, touchscreen devices.
