Tree Views are a standard control for looking at hierarchal data in a user interface. Avalonia has a TreeView Control as well. In this tutorial we are going to go over creating a TreeView control for a league roster system. This is based on a similar tutorial written for WPF by Mike Hillberg that you can find here except that we are skipping the manual list aspects of it. As an FYI, I’m doing my work in JetBrain’s Rider IDE so screenshots and instructions will be from there but this obviously works with any editor. You can find the final solution for this blog post in this Gitlab Repository.

A common way for displaying and manipulating tabular data is some sort of spreadsheet like area which is often called a data grid. In Avalonia that control is literally DataGrid. Starting with a standard project it’s relatively easy to get started however there are a couple of important steps that can be easy to overlook. We are going to go through starting from the default template all the way through to having an application that allows one to edit a data grid. You can find the final solution for this blog post in this Gitlab Repository.

There are many ways to lay out UI elements in Avalania from the StackPanel, which stacks things on top of each other or along side each other, to the Canvas which allows one to specify the exact pixel position of any element. The Canvas may sound like the way one would want to go because it gives the most control but in actuality it’s overl prescriptive. If you notice carefully how most user interfaces work they dynamically resize as windows are resized. They try to maintain a sense of proportionality with the drawing area being given to its window. The rigidness of the pixel-based system is sometimes useful but more often than not the panel type you’ll be wanting to use in Avalonia is the Grid. Here is the Part 1 of a multi-part series on the features of the grid and how to use it. You can find the final solution for this blog post in this Gitlab Repository.

In Avalonia Buttons Multiple Ways I went through a tour of the various ways one can bind buttons to commands and events. I wanted to explore the topic just a little deeper and look at some of the more advanced scenarios of dealing with binding behavior, specifically passing parameters to commands and setting the button’s enabled status based on other data in the View and View Model. Let’s build a little app to show how to do this, but you can find the final solution for this blog post in this Gitlab Repository.:

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.