Buttons are a pretty fundemantal UI element that we all must leverage. How does one go about interacting with and getting feedback from button clicks? It turns out there are multiple ways and there are no wrong answers but there may be some better answers than others. I’m going to go through the various ways one can intercept Button events, their feedbacks, and the pluses and minuses of each of those elements. You can find the final solution for this blog post in this Gitlab Repository. We are going to start with simple event actions that update a field in our view model. We will then look at how to wire in an asynchronous call to a dialog box to show handling feedback within the event handler. This will illustrate how Buttons that invoke besides directly changing a View Model field can be worked. The standard tutorial covers that case. The ways we will be attempting to wire up these buttons are:

• Responding to the Command via a simple Method on the View Model
• Responding to the Command via a Reactive Command response on the View Model
• Responding to a click event via XAML
• Responding to a click event via code
• Responding to a other events
• Adding Asynchronous Handlers

This is a long post so you may want to jump to the specific section of interest after you’ve completed the setting up of the project, or jump right to the conclusion.

Finally! I’ve been trying to get Jekyll code highlighting working since I first ported my blog. Earlier documentation says you have to install stuff which later ones said is wrong. “It just works” they say. Yet when I tried to get it working it always came up with nada! The documentation left out one really important part…the style sheets. It’s sad how long I went back and forth with this to have it simply be the equivalent of “is it plugged in”!

This week has been a crazy deep dive on Avalonia. I’ve managed to spend over 30 hours on it and related projects. Like with any new thing you learn things that were initially confusing have become more second nature. I think part of that is that I more than doubled the amount of time working with it in a pretty focused period of time. There were certain points where things were just coming together almost automatically in my mind. At one point everything was just humming but yesterday I hit a good sized roadblock trying to learn some more complex behaviors. It’s a common problem when learning anything, or even running. You hit this point when all of a sudden everything is just moving in complete efficiency and it starts feeling effortless. It can be euphoric, however like anything euphoric it wears off and a reality will set in eventually. Yesterday it was getting my face cracked trying to get a TreeView control working and getting notifications of event changes within DataGrids properly percolating around. To be fair this is getting into using this in more complicated ways which means that the simple responses in the developer assistance area is going to get harder and harder. Sometimes the answer is going to be “it depends” or “it can’t do that” or even “I think it should work like this but not sure”. I’m still going through the guantlet on it but still I’m stoked by the entire development experience, have a few applications I want to write in it, and am looking forward to contributing to the project.

When doing visual design of forms (or in this case views) it’s often best to see what it looks like with real data. Just like with mocking data in automated tests it’s possible to use a built-in XAML feature to achieve the same thing with graphical editors. It’s a XAML field called Design.DataContext. We’ll explore that here through the standard default auto-generated MVVM application which you can follow along how to create here. To see the final solution you’ll get at the checkout The Avalonia Example Repository and look at the DesignDataExample or browse directly here.

Getting started with a new library, framework, or development system requires two important things: documentation and code samples. With both of those a developer has enough to start fiddling with things and get bootstrapped. Code samples without documentation can be like searching a dark room without a light but is doable Documentation without samples can be far more difficult than that. In fact for more complicated APIs it can be impossible without source code, which I guess is sort of code samples in and of themselves. For a lot of projects the code samples I go to are the unit/automated tests. What better place to see how the library is used than in there. However having actual code samples, especially for more complicated libraries, is even better. In the case of Avalonia the project has shipped a “controls catalog” as part of their mainline source for a while now. However now you don’t have to pull down and build the full Avalonia source code to get it since there is a stand alone version of it. Here’s how to use it with Rider and AvalonStudio.