This week's giveaway is in the Java/Jakarta EE forum.
We're giving away four copies of Java EE 8 High Performance and have Romain Manni-Bucau on-line!
See welcome thread
Win a copy of Java EE 8 High Performance this week in the Java/Jakarta EE forum!

Stevens Miller

+ Follow
since Jul 26, 2012
Stevens likes ...
C++ Java Netbeans IDE Windows
Forum Moderator
Stevens Miller currently moderates these forums:
I'm a military brat (Navy) who has not yet figured out what he wants to be when he grows up. I have programmed computers for over 40 years. I have a law degree. I've been elected to public office. I love science fiction. I love to cook. I love my wife and my son (more than even science fiction and cooking). I run the lights for community theater productions. I was born in Japan (that Navy brat thing again). I am a capitalist who believes in socialized health care, because I think retail health care makes as much sense as retail national defense, and I certainly believe in a strong national defense. Also, if it weren't for a certain amount of socialism, every street in America would be a toll road. But equal opportunity ought not to mean guaranteed results. Anyway, that's how I see it. You?
Northern Virginia, USA
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Stevens Miller

I've released my first beta of a free software library that allows Java programmers to get easy access to XBox 360 controllers plugged into USB ports on their computers running Windows. Yes, it's platform-specific, but maybe this is only a start.

The library is called J360Controller and it's up on SourceForge. A complete tutorial is also online, as well as full javadoc.

Using this code, your application can poll the controller, or it can register listeners. It supports a variety of ways to react to changes in trigger/joystick positions, allowing values to keep changing when a trigger or joystick is off-center (or off-zero), which might be useful in a game where you want to control a vehicle or the direction of a cannon. Also, you can link the hard buttons on the controller to JButtons in your application, and you can link the triggers/joysticks to JSliders.

The tutorials give small, complete, working examples. I'd be delighted to know what people think and to hear suggestions for improvements.

The .jar file is all you need to try it. That's in the "Files" tab. If you're interested in the source, that's in the "Code" tab, as a git repository. I've never used git or SourceForge before, so I'd be happy to have suggestions on making better use of those things, as well.

9 months ago

Hank Emery wrote:

Stevens Miller wrote:In your Character interface, how do you specify what/who is being attacked?

AH! attack should have a parameter. Thanks for the correction.

You made that change in your Weapon interface. I asked about your Character interface. How does your Character interface specify the object being attacked?
10 months ago
In your Character interface, how do you specify what/who is being attacked?
10 months ago
Let's focus on use for now. What does it mean to "use" a weapon? That probably varies from one weapon to the next, which means your decision to create an abstract class makes sense (note, by the way, that an abstract class with no concrete methods nor member fields should probably be an interface). I'll assume that a weapon does damage and that the damage is reflected in a change of state in a character (loss of HP, for example). A character might have defenses available that could be more effective against some weapons than others. Also, some weapons might be probabilistic (you could miss, for example) as well as being more effective against some characters than others (holy water would cost a vampire HP, but have no effect on a troll, maybe).

So, if you follow Stephan's suggestion and pass a reference to the character under attack to the weapon's use method, the weapon's effect can combine how it works with who it is working on. For example:

Now, this code has some advantages and some disadvantages. One advantage is that you can use any Weapon on any Character, and the result will depend on both what the Weapon is and what the Character is, but your calling code neither knows nor cares about either. All Weapons and all Characters are generic at the calling level.

A big disadvantage is that your Character class must implement a new takesAHitFrom method for each new Weapon you create. This is a side-effect of the "coupling" between Weapons and Characters (that is, it arises from the fact that the result of using a Weapon on a Character is, literally, a function of both the specific type of Weapon in use, and the specific type of Character the Weapon is used on). But, it gets you out of a bunch of ugly instanceof tests you might otherwise end up using, and that's a good thing.

I've considered something like this problem before, which is where the code above came from. You might find that discussion helpful. Also, you have attracted the attention of Stephan van Hulst, and that's a good thing too. He knows what he's doing, and I always learn a lot from his contributions.
10 months ago
I like Stephan's approach. Note that he has every Item defining its own use method, instead of every Character having multiple use methods. In this way, a Character can use as many Items as it has, without needing define any use methods at all. In this approach, it is the Item that knows how it is used, not the Character.
10 months ago
Thanks. I promised more info, but have gotten a bit bogged down by some related stuff. Will be back soon, though.
10 months ago
Okay, so after an overwhelming groundswell of response, in which seven votes were cast by three people, the consensus answer appears to be, "rarely." I like that as, even though I can write a good Java program, it would be risky to assume my Java is fluent enough to use it to explain anything that was already hard to explain in Visual Basic, except maybe in the uncommon situation where something abstruse in one language is a clear match for something equally abstruse in both languages.

10 months ago
I see these "How To" posts about Visual Basic are getting some views, which is great. So far, I have refrained from making any comparisons between how something might be done in Visual Basic and how the same thing might be done in Java (except, of course, for the post with the Java-to-Visual Basic cheat sheet). That's because not everyone seeking to learn Visual Basic is an old hand at Java. However, even though the Big Moose Saloon isn't just a Java community, it seems pretty clear that a lot of ranchers are Java programmers. So, the question is this:

11 months ago
It's easy to set a Button's background color in XAML:

Wiring it up with a name and a click event-handler makes it easy to change that color in code:

But that would grow tedious if you wanted to set a lot of buttons or other controls, particularly if you wanted to set them all to the same color. Fortunately, there's a way for any number of them to rely on a shared setting you only have to change once for the change to be made to them all.

First, you define a named "resource," like this:

Line 2 gives this resource its name, "interiorColor" (you can pick any name you like). To use it, you replace the Button's Background property with a reference to the resource, like this:

Note that the Background value is still enclosed in double-quotes. Now the XAML compiler knows it must look up the value by finding the resource named "interiorColor." Because we want to be able to change it at run time, we have declared this to be a "DynamicResource," as opposed to a "StaticResource," which is fixed for the run of the application.

In our click event-handler, instead of setting the Button's background color, we'll look up and change the setting of our resource:

Note that "Resources" is a property of the Window that encloses the Button, not a property of the Button itself. Note also that "Item" is a property of the Resources property (which is a ResourceDictionary object). And finally, note that the Item property is indexed by the "interiorColor" string, used as a key. (Okay, really finally, note that the item, once you've looked it up, is assigned a new SolidColorBrush object, not just a color; WPF fills regions with brushes, which have colors, not with the colors themselves.)

Now, when we click the button, the resource value changes. And, any element with a property set to that resource is updated with the change. That means we can have several Buttons, all sharing that resource, which all change when the resource changes:

The Buttons defined in Lines 1 and 2, above, will change color when that first Button we defined above is clicked. Note that the Button created at Line 3 refers to "interiorColor" as a static resource. This means it will not change color. This illustrates an important characteristic of resources: a resource is not, by itself, either static or dynamic. Rather, references to those resources are either static or dynamic, with static references looking up the value once, and dynamic references monitoring the value for changes, and updating their elements when a change is detected.

Next, I'll show how more than one attribute of an element can be grouped into a set, again shared by multiple elements, and how to deal with elements that have some, but not all, of their attributes in common.

11 months ago
Elsewhere, I mentioned that it is easy to label a WPF Button with more than one line of text. However, the trick I used to do it left-justified the text, which isn't how I will always want it. I also mentioned that I didn't know how to center it, but made the tantalizing comment that I might, "come back another day," pursue it.

Today's that day. The question is, "How can I center multiple lines of text in a WPF Button?" I'm sure there are many answers, some likely better than what I'll venture here. But, the XAML below does seem to work. It is based on the fact that a WPF Button can contain all sorts of things, not just text. The picture below shows five XAML Buttons, but only the first two have plain text as their content:

Here's the XAML that defines those Buttons:

At Line 10, I have again used my crude trick of embedding a DOS newline in the text. The first Button displays the two lines, left-justified. Note, however, that the "equivalent" XAML at Lines 12-14 doesn't work. The second Button is back to using one line. So, the newline "method" is not recommended.

Here's where we stop using text as the content of a Button altogether. For the third Button, defined at Lines-16-21, we replace the text as the Button's content with a StackPanel element. Nested inside that, we include two TextBlock elements as the StackPanel's content. Finally, the content (somewhat confusingly set with the "Text" property) of those TextBlock's is set to the original two lines of text we used in the previous Buttons. The result, in the third Button down from the top, is the left-justified text we had in the first place. To center it, we simply add the HorizontalAlignment property to each TextBlock and assign the value of "Center." That's how the fourth Button is defined at Lines 23-28 (with the TextBlocks at Lines 25 and 26).

Note that quite a wide variety of elements can serve as the content of a WPF Button, beyond text and TextBlocks. For example, the fifth Button is defined by Lines 30-32. Its content is an Image element, the source of which is actually a URL, with the image file residing somewhere on the Web. The wisdom of using Web resources for UI controls is debatable, but Line 31 does, I think, a striking job of illustrating how far a WPF Button's contents can be from plain text, and how easily the required XAML code can cross that distance.

Note also that this post, which I have originated in the Visual Basic forum, contains no Visual Basic. As per the WPF design goal of being usable in all .NET languages, the XAML here would work just as well in, say, a C# context as it does in a Visual Basic context (hence, I am adding the C# forum to this posting).

I'm reading Adam Nathan's "WPF 4.5 Unleashed," which is an excellent guide to WPF and XAML. (Its example code is all in C#, but there seems to be little effort required to mentally translate that into Visual Basic, especially if one already knows C/C++ and/or Java.) I'm not usually a fan of the "Unleashed" books, as their editorial style is often a bit unfocused, I feel. This one is different. If you are looking for a book on WPF, this is the one you are looking for.

More soon...
11 months ago
I want to be able to use my touchscreen (on my Asus laptop) to press buttons on my Visual Basic applications. Now, here's a funny thing about buttons: In general, the methods that handle their "click" events do not get called when they are pressed; those methods are called when the buttons are released. If there is an advantage to this, it may be that you get one last chance to avoid clicking a button you may have pressed by mistake (a chance you use by dragging the mouse pointer off of the button before you release the mouse button).

But, that's not how a real, physical button would work. Those tend to generate whatever action they govern when you press them down. There's no real-world action that is comparable to dragging a mouse pointer off of a button, so there's no sequence of events you could follow that would let you press a physical button down, yet somehow indicate you didn't want its associated action to occur. In short, by the time you have pressed a physical button down, it's too late to undo it. If there's an advantage to this, it may be that you can be sure that the action you want will happen immediately upon the press, not some time after (which is immediately upon the release, for a typical virtual button you click with a mouse).

If you like that on-the-release behavior, then your touchscreen will partly make you happy. That's because, again, the "click" doesn't happen until you lift your finger from the screen. But, I say "partly" because even the mouse-down event doesn't happen until you lift your finger. For whatever reason, the buttons you add to a Visual Basic application's UI with Windows Forms do not "know" you have touched the screen until you untouch the screen (or, curiously, until you move your finger while touching the screen).

I'd like to see immediate feedback and I'd also like the click event to occur upon touching, not upon untouching, the screen, so the screen button and physical button will behave as much like each other as they can. Windows Presentation Foundation lets me do that.

Here's a simple Windows Forms application with handlers that check the appropriate boxes upon the MouseDown and Click events:

Here's what happens when, after shifting the focus to that "Clear" button, I touch the "Press Me!" button (which has those event handlers connected to it):

That's right. Nothing happens. No events fire. The focus doesn't even move.

If I wiggle my finger on the screen surface a bit, the focus does move and I get the MouseDown event:

Finally, if I lift my finger (with or without wiggling it first), I get both events:

Well, that's not what I want, though it's a bit tantalizing as, somehow, Windows does seem to know I have touched the screen (else how could it react to my wiggling finger?). It's tempting to pursue it in the hope that we could use the MouseDown event to call a handler and get the behavior we want. But, even if we could, that's really a dead-end. Here's why: if you use the keyboard to press the button, you never get a MouseDown event at all. Here's the "Press Me!" button after it has received the focus and while the space bar is subsequently being held down:

Again, no events (although the button does darken in color a bit, providing visual feedback that it is being pressed). Here's the situation after the space bar is released:

We finally do get our Click event, but no MouseDown event is ever fired. Using MouseDown to know when a button has been clicked is a non-starter.

What about Windows Presentation Foundation? WPF solves both our problems, one automatically, and one optionally.

Here's the approximately identical application written with WPF (we've again used our XAML skills to make the button change color and seem to recede a bit when pressed):

Note that this is doing everything we want: the button reacts visibly when we touch the screen, and the Click event fires on the "finger down" event, not upon release. The first feature, of reacting upon touch, is automatic with WPF. It just works that way. The second, of firing the Click event upon press (instead of waiting for release) is an option. All we had to do was add the ClickMode attribute to the Button element in our XAML code: "ClickMode" is also settable in the Visual Studio property sheet when the button is selected in the designer.

Now I can have touchscreen buttons that behave like real-world buttons do, with visible response upon contact, and immediate action.

By the way, you may have noticed something else about those WPF buttons that you don't tend to see on Windows Forms buttons: multiple lines of text. Look back at that XAML, above. See the Content attribute? That clumsy string that is its value inserts the hoary Windows (nay, DOS) "newline" sequence into the text string. WPF buttons can handle that. Try it as the text of a Windows Forms button, and you'll get a button that says, "Press
Me!" on your screen.

Now, that text is left-justified and I admit that's probably not what I want. Centered is probably what everyone would want. But I don't know how to do that yet, so we'll end here with the answer to the question I asked in the first place, and come back another day to ask more about WPF buttons and their content.
11 months ago
In an earlier post, 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 depth 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: 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 moved by these new values. Let's try it.

Here's the button when it's just sitting on its own:

Here's the button when the mouse is hovering over it:

And here's the button when the left mouse button is pressed:

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 application.xaml for us, and allowed us to edit it from there. "What?" you may ask, "Do I have to do that every 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.
11 months ago
Thanks for the background, Les. Very informative.

Claude Moore wrote:I've read that Microsoft isn't going to evolve Visual Basic further, is that true ?

Where did you see that, Claude? As I recently posted in another thread in this forum, it tends to be easy to find someone, somewhere, who will tell you that whatever language/operating system/toolkit/framework you are using is dead when it's actually thriving. Try Googling "Java is dead" and you'll see what I mean.

But, as I also conceded in the same comment, Microsoft does have a tiresome tendency to announce "no further enhancements will be made" regarding lots of their current technologies. Over the many years I've used Microsoft products, I've just learned to live with it.

Regarding C# and Visual Basic as alternatives, this paragraph from Wikipedia is interesting:

Wikipedia wrote:C# and Visual Basic .NET are Microsoft's first languages made to program on the .NET Framework (later adding F# and more and others have also added languages). Though C# and VB.NET are syntactically different, that is where the differences mostly end. Microsoft developed both of these languages to be part of the same .NET Framework development platform. They are both developed, managed, and supported by the same language development team at Microsoft.[8] They compile to the same intermediate language (IL), which runs against the same .NET Framework runtime libraries.[9] Although there are some differences in the programming constructs, their differences are primarily syntactic and, assuming one avoids the Visual Basic "Compatibility" libraries provided by Microsoft to aid conversion from Visual Basic 6, almost every command in VB has an equivalent command in C# and vice versa. Lastly, both languages reference the same Base Classes of the .NET Framework to extend their functionality. As a result, with few exceptions, a program written in either language can be run through a simple syntax converter to translate to the other. There are many open source and commercially available products for this task.

An Infoworld article by Paul Krill supports the above. It might be noteworthy that Krill's article was written in 2009, and refers to Visual Basic 10 and C# 4. The latest Visual Studio lists these components when you click "Help / About Microsoft Visual Studio:"
Microsoft Visual Studio Community 2017
Version 15.0.26228.9 D15RTWSVC
Microsoft .NET Framework
Version 4.6.01586
Installed Version: Community
Visual Basic 2017 00369-60000-00001-AA466
Microsoft Visual Basic 2017
Visual C# 2017 00369-60000-00001-AA466
Microsoft Visual C# 2017
Visual C++ 2017 00369-60000-00001-AA466
Microsoft Visual C++ 2017
Application Insights Tools for Visual Studio Package 8.6.00209.10
Application Insights Tools for Visual Studio
ASP.NET and Web Tools 2017 15.0.30223.0
ASP.NET and Web Tools 2017
Common Azure Tools 1.9
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.
JavaScript Language Service 2.0
JavaScript Language Service
JavaScript Project System 2.0
JavaScript Project System
JavaScript UWP Project System 2.0
JavaScript UWP Project System
Microsoft Visual Studio VC Package 1.0
Microsoft Visual Studio VC Package
NuGet Package Manager 4.0.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit
TypeScript tools for Visual Studio
Visual Studio tools for CMake 1.0
Visual Studio tools for CMake
Visual Studio Tools for Universal Windows Apps 15.0.26228.00
Right at the top there you can see both Visual Basic and C# designated as their 2017 versions. I suppose Microsoft could just renumber the same old program with every release of Visual Studio, but I doubt they'd do even that much if they wanted to put a language out to pasture.

It is also interesting to compare the historical ranking for C# with the historical ranking of Visual Basic. C# ranks a bit higher, but has trended downward since its peak in 2012, while Visual Basic has trended upwards over the same span of years. (Not that the Tiobe index is conclusive, but it is interesting.)

I think Les's characterization is quite apt. Back in the '80s, a computer researcher I knew predicted that, "eventually, all languages will converge to something like C." Being a long-time C fan, I tried C# first, when I was recently motivated to look for an all-Microsoft way to get something done. (Mostly, I write in Java and use the JNI when I need something specific to Windows that Java can't do on its own. This time, I needed to avoid relying on there being, or having to install, a Java Runtime Environment on my users' machines.) I was kind of surprised by how much if, at least upon my first glance, did not look like C. In particular, I saw some stuff in square brackets that kind of put me off. Having learned Visual Basic long ago, I looked at that again. Imagine my surprise to discover that, since my last go-round with it (when it was still called Visual Basic 6), it had become a truly object oriented language.

While it is true that Visual Basic does not use curly brackets, nor end a statement with a semicolon, I'm pretty much finding that its current form makes writing the Visual Basic equivalent of a Java method mostly a matter of looking up the comparable keyword. (I posted a handy cheat-sheet that illustrates how much the two languages have grown alike, grammatically if not syntactically.)

So, it appears that, for now, whether one uses C# or Visual Basic is a matter of personal preference, there being no capability unique to either. And, as far as I can tell, Microsoft remains equally committed to both for the foreseeable future (which, when we are talking about Microsoft, maybe only be about twenty minutes, but that's how it is for both languages.)

Hope you'll post here often. New forums need new input!
11 months ago

Stephan van Hulst wrote:Cool, thanks Stevens!

You're most welcome, and thanks for being one of this new forum's first reader/commenters.

XAML is the main reason I have not strayed from old Windows Forms applications yet.

It certainly is daunting. Microsoft's documentation praises it for making so many things "easy," including: isolating UI design from business logic implementation; decoupling form from function in the various controls themselves; simplifying the creation of custom controls; and (for some reason) further streamlining the use of controls by subdividing the structural and cosmetic portions of a control into, respectively, styles and templates.

All of which I am presently thinking is a lot of nonsese. The very idea that I should have to learn yet another cryptic XML-based, CSS-like "language," just so I can set a color, is mind-boggling. Fact is, I wouldn't be digging into XAML at all, this early into my Visual Basic investigations,were it not for the point of this post: the out-of-the-box implementation of a WPF Button fails to do the most basic thing a GUI button should always do, which is change appearance when pressed. I quite hope that someone who knows why Microsoft thought changing it from a pale, ashen, light sky blue to a pale, ashen, light robin's-egg blue was a good idea will find this post and share what they know.

I think Visual Studio's Forms designer is also much friendlier than the WPF designer. When I eventually have to bite the bullet, I'll come back to these posts.

This is also something that seems to have gone through some evolution. Visual Studio includes a designer and it does work. But you can also open your UI files in "Blend," which used to be known as "Expression Blend," and maybe by a few other names. Some people say this is more powerful, while others say all it does is keep the developer stuff out of the UI designer's field of view. I've tried Blend and, honestly, it all looks a lot like Visual Studio, just with the furniture rearranged.

I also still need to get into JavaFX, after being intimately familiar with Swing.

I've tried to start down that path a couple of times, but it seems very opaque. And I do love Swing. Once you get the hang of its MVC/PLAF architecture, it can do quite a bit for you. Alas, one thing it does not do is react to touchscreens very well. For whatever reason, when you click on a JButton with a mouse, you get the MouseDown event immediately, and can react to it if you want to (before the MouseClicked event is sent). But, with a touchscreen, you don't get a MouseDown event until either you release the button, or move the cursor on it. I believe this is also the case with buttons under Windows Forms. But, with WPF, you can set the Button so that its "click" even is sent upon a mouse-down, which is exactly what you want for a touchscreen. I've tried it and it works well. (I'll do a post on it.)

I really dislike having to learn all these new presentation layer technologies.

Brother, I feel your pain. And it always seems like, no matter which one you think you should be learning, there are plenty of folks who will tell you your choice is dead. Indeed, even though WPF appears to be the latest framework from Microsoft for desktops, I found an article on a panel discussion with some MS developers who said nothing new was likely to be added to it (and that was in 2014!).

I guess part of the problem is that most new work is being done for Web clients, so it's all about JavaScript, CSS, and so forth. The "GUI" is the browser, these days. But people do still develop desktop apps, so we do still need UI platforms for them.

I also have a theory that Microsoft (among others) never likes to let anything they develop get too old, for fear that competitors will use relatively recent advances in design, hardware, method, etc. to offer superior alternatives. It does seem like, just about every time I dig into a new MS tool, it never takes more than a year before they announce it's in maintenance mode and I am considered obsolete. (Good example of that, and of why it's not always as bad as it seems, is DirectShow. They say it's been replaced by WMF, but there are tons of things WMF still can't do, that DirectShow can, so it still exists and you still have to use it for a lot of things.)

Glad you're interested. I'll be looking forward to grappling with Visual Basic with your help.
11 months ago
The old(er) Windows Forms buttons provided definite visual feedback when "pressed" (that is, when clicked with a mouse). Here's how a Forms button looked when enabled and the mouse wasn't over it:

And here's how it looked when you hovered over it with the mouse:

Finally, here's how it looked when you clicked and held the mouse button down:

Those last two aren't exactly as different as black and white, but the user does see an unmistakable change in appearance when a Windows Forms button is actually pressed.

Now compare the images above to the same three contexts applied to a Windows Presentation Foundation ("WPF") Button. Starting with enabled and not being hovered over:

Here it is with the mouse hovering over it:

And here it is being pressed:

If you think you see a very, very slight difference in appearance between those last two, you're right. The pale blue background of the "hovering" Button is this mix of red, green, and blue: 0xC4E5F6 (or, Red = 196, Green = 229, Blue = 246, on the 0-to-255 integer range of RGB values). The pale blue background of the "pressed" Button is this mix: 0xBEE6FD (or, Red = 190, Green = 230, Blue = 253). That's a difference so slight, one might wonder why Microsoft bothered to change it at all. In fact, if you look very closely, you will see the single-pixel border also changes a wee bit, from 0x3C7FB1 to 0x2C628B, a slightly bigger change, but still hard to see.

How to make the change more significant?

This is where it all goes nuts... Microsoft appears not to be using the Model/View/Controller approach that Java Swing controls use. Instead, they use a baffling mix of three things: object properties, styles (vaguely like CSS), and templates. The last two are expressed in "XAML," Microsoft's XML-based eXtensible Application Markup Language (and pronounced ZAM-el). I'm not yet fully educated on what the difference between a style and a template is, but I do know you use a combination of the two to render a much more noticeable change when a WPF Button is pressed. Also, although it will seem somewhat grotesque, it is easy to do.

Start with a right-click on the button in the designer, and pick "Edit Template / Edit a Copy..."

In the dialog box that appears, select "Apply to all," and "Application." (Note that, although you chose "Edit Template," from the menu, the dialog box is titled, "Create Style Resource." This will not be the last time you find templates and styles weaving in and out of each other.)

Then click "OK."

What happens next may astound and also disgust you.

In the file, "Application.xaml," you will find dozens of lines of XAML code resembling this:

If you look at Lines 19 and 21, you may recognize something: the Color attributes match what we observed as the "hovered" and "pressed" colors of the WPF Button (those leading "FF" values are transparency settings, where FF is full opacity). We can change the "pressed" value to something dramatic, like full red, with "#FFFF0000." If we do, run the program, and press the button, here's how it looks:

Yow! That really did change the look of the pressed button. Well, that's what we were after, so I guess that's progress. Now, because we told the IDE we wanted this to affect all buttons in the application, we should be able to create another button and not have to go through all this work again. Let's try it by adding a second button to this window (which the Visual Studio IDE calls a "document," by the way).

NOTE: There appears to be a bug in Visual Studio (both VS2015 and VS2017RC) that will corrupt your program when you add a second button unless you close and reopen Visual Studio first. The effect can be seen in the Application.xaml file. You can copy the file elsewhere and restore it after it becomes corrupted as an alternative to closing and reopening VS.

Here's what happens when we do that and run it:

So, it appears we did make a change that, as intended, applies to all WPF Buttons in the application. Indeed, if you create an entirely new WPF window and add a Button to it, then add the code in the Click event for one of the Buttons in the window above to create and show your new window, you will see that the background of that Button also changes to red when it is pressed.

Next post, I'll show how you can use XAML to give a WPF Button that delightful old, early Windows effect of moving a bit when it is pressed.
11 months ago