DesktopXAMLContainer – Xojo Programming Blog

Xojo + XAML + Goto = 🔥

William Yu — Thu, 22 Jan 2026 20:50:59 +0000

For decades, Goto has been treated as a programming faux pas—something to avoid at all costs. Like most rules though, there are exceptions. The Goto I’m talking about here is one of them… and it can quite literally light your app on fire—programmatically speaking.

One of the hidden gems in Xojo 2025r3 is support for XAML transitions, which makes it possible to add lightweight animations to your UI without writing any custom animation code in Xojo. Instead, you define visual states in XAML and let the XAML engine handle the animation for you.

At a high level, the workflow looks like this:

Define one or more VisualStates in XAML.
Attach transitions to those states (for example, moving or fading an element).
From Xojo code, switch between states using Invoke("GotoState", ...).

Pro Tip
DesktopXAMLContainer subscribes to Operator_Lookup, so you don’t have to call Invoke directly. Instead of writing XAMLContainer1.Invoke("GotoState", "WhichState"), you can simply call XAMLContainer1.GotoState("WhichState").

Visual States in XAML

A VisualState represents a named configuration of UI properties. When you transition from one state to another, XAML can automatically animate the change.

Below is a simple example that animates a fire emoji moving upward, similar to a candle flame flickering or burning upward.

Example XAML

This example uses a TextBlock to display the fire emoji and animates its vertical position with a TranslateTransform. Note that visual states must be defined on a control, so we attach them to a UserControl, allowing it to participate in GotoState transitions.


  
    
      

        
          
                          Storyboard.TargetName="FlameTransform"
              Storyboard.TargetProperty="Y"
              To="40"
              Duration="0:0:1" />
          
        

        
          
                          Storyboard.TargetName="FlameTransform"
              Storyboard.TargetProperty="Y"
              To="-100"
              Duration="0:0:1" />
          
        

      
    

          Text=""
      FontSize="32"
      HorizontalAlignment="Center"
      VerticalAlignment="Bottom">

In this XAML:

The VisualStateGroup named FlameStates contains two states:
- Bottom – moves the emoji downward.
- Top – moves the emoji upward.
The DoubleAnimation targets the Y property of a TranslateTransform.
The transition duration is handled entirely by XAML.

Triggering the Transition from Xojo

Once the visual states are defined, switching between them from Xojo is straightforward. Assuming this XAML is hosted in a XAMLContainer named XAMLContainer1, you can trigger the animation like this:

XAMLContainer1.GotoState("Top")

And to move it back down:

XAMLContainer1.GotoState("Bottom")

Why This Is Powerful

What makes this feature especially useful is that:

The animation logic stays in XAML, where it naturally belongs.
Xojo code remains clean and declarative—just tell the UI which state to go to.
More complex effects (opacity, scaling, rotation, easing functions) can be added without changing any Xojo code.

Here’s a more interesting variation, where the flames drift upward rather than moving in a straight line:

To light up the flames we’ll simply invoke the “On” state:

XAMLContainer1.GotoState("On")

For subtle UI polish—like animated indicators, highlights, or playful effects such as this candle flame—XAML transitions provide a surprisingly powerful new tool in Xojo.

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

Toward the Future with WinUI

William Yu — Tue, 09 Dec 2025 16:30:10 +0000

Keeping up with innovation can be challenging, especially when new technologies don’t always align neatly with what came before. Microsoft works hard to find a balance, they experiment, iterate, and refine to discover what their users really want.

We’re taking a similar approach with our WinUI transition. We began with the DesktopXAMLContainer and are continuing by updating our Win32 controls to their WinUI counterparts, aiming for steady progress without disrupting existing workflows.

What can you look forward to in 2025r3?

We’ve expanded our WinUI offerings in this release with a broader set of updated controls. While 2025r2 introduced only a handful of WinUI-backed controls, 2025r3 builds on that foundation by updating a much larger group, including: BevelButton, Label, UpDownArrow, DateTimePicker, ComboBox, PopupMenu, RadioGroup, SegmentedButton, DisclosureTriangle, MoviePlayer, SearchField, TextField, and TextArea.

What are the benefits of using WinUI?

Win32 controls have been the foundation for many Windows apps, but WinUI introduces capabilities that traditional Win32 controls don’t have. Here’s a comparison to highlight some of the differences:

A Win32 DesktopLabel with a colored emoji is rendered in black and white.

Compared to the WinUI version with a colored emoji.

A Win32 DesktopTextField containing right-to-left text isn’t automatically recognized as such, so it renders left-to-right.

Compared to the WinUI version which can automatically detect right-to-left text and formats accordingly.

A password field (via DesktopTextField) with primitive support on Win32.

An actual WinUI version of their PasswordBox control with a preview widget.

A Win32 DesktopComboBox which does not support separators.

A more modern looking WinUI version with built-in support for separators.

A Win32 DesktopDateTimePicker with a dropdown calendar, but does not support dark mode.

A more modern looking WinUI version that also supports dark mode.

Win32 dark mode support is limited.

WinUI dark mode support is easier on the eyes.

The Win32 DesktopMoviePlayer is very dated.

WinUI has a much more modern look and feel.

Opt-in to WinUI

If you’d like to preview how your apps look and feel with WinUI controls, open the Windows build settings and check the options under the Advanced widget tab. Selecting “Use WinUI” applies WinUI styling to your desktop controls while keeping them scaled to your existing Win32 control bounds. Opting into “Native Control Sizes” gives you a more accurate representation of a true WinUI app, using the larger default font size and correspondingly larger controls.

More Work Ahead

As we continue down this path, we’re uncovering pain points that developers face when using WinUI controls in a Win32 environment—challenges Microsoft is no doubt familiar with as well. It will take time before we can fully move away from Win32 controls/windows and embrace WinUI, but we’re steadily heading in that direction. Thanks for joining us on this experience, more to come!

A XAML Driven UI

William Yu — Tue, 08 Jul 2025 18:01:00 +0000

If you’re building rich, maintainable and scalable user interfaces on Windows, XAML is a great choice. Its clean, declarative syntax and solid separation between design and code can make things easier to manage, and since it’s tightly integrated with the Windows UI system, it can really help take your app from basic to polished.

Migrating Towards XAML

We are slowly and selectively updating our Win32 UI to the more modern WinUI with the help of XAML. You’ll notice some incremental updates in 2025r2 to this effect when you’ve got the Use WinUI (Experimental) build setting selected.

For those who can’t wait for our Win32 UI updates or need more advanced XAML layouts today, the DesktopXAMLContainer provides a powerful and flexible solution with virtually unlimited possibilities.

For a quick refresher, please take a look at a blog post we did when we first introduced the DesktopXAMLContainer control.

A Deeper Dive into XAML

While previous blog posts have showcased the potential of using DesktopXAMLContainer, there’s still much more to explore when it comes to effectively using and understanding XAML within Xojo.

XAML is Asynchronous

Understanding that XAML operates asynchronously helps explain why setting or retrieving a property might not behave as expected—especially when a control hasn’t fully finished constructing. To reliably detect when a XAML control is ready, use the EventTriggered event and check if the eventName is “Loaded”. This is particularly important when working with complex layouts that include XAML controls containing embedded XAML content.

Due to the asynchronous nature of XAML control rendering, the DrawInto mechanism also needed an enhancement. For DesktopXAMLContainer, we’ve added an asynchronous variant DrawIntoAsync, which renders the control and returns a Picture via the supplied callback method.

Sub RenderXAMLPreview(container As DesktopXAMLContainer, targetCanvas As DesktopCanvas)
  // Pass the canvas as the user data so we know where to draw
  container.DrawIntoAsync(AddressOf XAMLDrawComplete, targetCanvas)
End Sub

Sub XAMLDrawComplete(image As Picture, data As Variant)
  If image <> Nil And data IsA DesktopCanvas Then
    DesktopCanvas(data).Backdrop = image
  End If
End Sub

Translating your XAML Experience

Rotating and scaling a XAML layout is as simple as applying the appropriate RenderTransform. In the following example, we rotate a XAML CheckBox within a Timer.Action event. Even though the entire XAML content is updated on each timer interval, the result remains smooth and fluid, demonstrating how well XAML handles dynamic visual changes.

Sub Timer1.Action()
  Static angle As Integer = 0

  angle = angle + 10

  If angle >= 360 Then angle = 0

  Var isChecked As Boolean = True

  If XAMLContainer1.Content <> "" Then isChecked = XAMLContainer1.Value("CheckBox.IsChecked")

  Var xaml As String = "" + _
	"" + _
	"" + _
	"" + _
	"" + _
	"" + _
	""

  XAMLContainer1.Content = xaml
End Sub

Child Controls Inherit the Parent’s Background Brush

When embedding a Transparent DesktopXAMLContainer on top of another, the child will inherit the parent’s background brush. This is useful for basic brushes, but note that it does not support acrylic brushes and won’t automatically adjust offsets for linear gradient brushes.

Layering XAML

WinUI and Win32 controls are rendered on separate layers. WinUI content is composited first, then Win32 controls are drawn on top. As a result, any Win32 control will always appear above WinUI content unless you directly parent a DesktopXAMLContainer control on a Win32 control.

Setting Focus for Embedded XAML Controls

Starting with 2025r2, you can now set focus to a specific control in your XAML layout. Here’s how this looks:

This layout uses a StackPanel with three vertically arranged buttons inside a single DesktopXAMLContainer. To set the focus to Button2, you would invoke Button2.SetFocus

XAMLContainer1.Invoke("Button2.SetFocus")

Extended XAML Features

As mentioned in a previous blog post, we’ve extended XAML with a new markup syntax unique to Xojo. The primary goal of this extension is to improve the reusability of XAML controls. For example, consider a layout that includes three different XAML buttons:

Updating the caption or changing the button’s color would require manual edits to the XAML content string. Wouldn’t it be more convenient if those properties were available directly in the Inspector? With a custom subclass, some tweaks to its Inspector behavior, and the Xojo-specific {XojoBinding} syntax, you can make that happen.

First, create a subclass of the DesktopXAMLContainer, we’ll call this our XAMLButton, and add the properties that you want to expose in the inspector.

We’ll modify the XAML content to use the new {XojoBinding} syntax, which dynamically replaces the placeholder with the corresponding property value from the Inspector based on its name.

Now you can just drag out your subclassed control and adjust its properties directly in the Inspector without needing to manually edit the XAML content.

Make sure to check out our XAML Subclasses example project to see the other possibilities.

Having Fun With XAML

With a better understanding of XAML and how it integrates with Xojo, you’re now ready to build a XAML-driven UI on Windows. In fact, our IDE already makes use of XAML in several areas, like the Splash Screen, the XAML Control Chooser dialog and the toolbar in the Documentation window. The possibilities with XAML are vast, so dive in and explore what it can do for you!

WinUI and A Box of Shadowy Changes

William Yu — Tue, 25 Mar 2025 15:32:59 +0000

Occassionally we make fixes and additions that might seem minor to some, but a highlight for others. Take for example our changes to the DesktopWindow Shadowed Box type. At first glance, this change might not seem significant, especially for macOS and Linux users, where no upgrade was required. But for Windows users, it’s a small yet important step toward something even better.

Making Your App Stand Out

Designing an app that stands out can be a challenge, but sometimes, a simple UI refresh can make all the difference. One small yet impactful step in that direction was improving the Shadowed Box frame type of a DesktopWindow. If you’ve ever tried using it on Windows, you likely noticed a frustrating limitation—the title bar never fully disappeared. What should have been a sleek, borderless look was instead marred by a stubborn, shrunken title bar, making it easy to abandon the feature altogether, and perhaps preferring to use the Plain Box type instead.

Notice that the title bar isn’t entirely removed.

With Xojo 2025r1, this is no longer a problem. The title bar now disappears entirely on Windows, just like it does on macOS and Linux. This makes it even more effective for use cases like splash screens, which appear much more dynamic compared to the flat look of the Plain Box type.

Modernize with WinUI

Our Splash Screen is a small example of what’s possible with WinUI through our DesktopXAMLContainer. For 2025r1, we’ve enhanced DesktopXAMLContainer by adding support for additional methods, properties, and events for WebView2, as well as support for the MediaElement control. We’ve also improved tab navigation between WinUI controls within a DesktopXAMLContainer and non-WinUI controls in your layout. Additionally, WinUI layout controls like StackPanel and Grid can now resize to the bounds of your control, instead of just resizing to fit content. This makes background fills, such as acrylic brushes, easier to manage. As we keep advancing Xojo’s WinUI support, you can start taking advantage of these shadowy changes today. Check out our XAML example projects included in the Xojo download Examples folder to see what’s already possible!

TabPanel has Finally Joined the Dark Side

William Yu — Tue, 26 Mar 2024 15:26:49 +0000

Xojo’s TabPanel on Windows has fought hard to stay on the light side by making the dark mode transition annoyingly difficult, but at long last it has given up the fight and has embraced the dark side.

Supporting dark mode with Win32 controls is never an easy exercise, but if you’ve been following along with our work to modernize our Windows framework with XAML, then you may have already updated your apps with the XAML TabView control that natively supports dark mode.

Simply plug this bit of XAML into our DesktopXAMLContainer Content property and you’ve got yourself a modern looking TabPanel that already supported dark mode even before we did.

While people debate on which mode (light or dark) they prefer to work in, you can ultimately control whether you want to support dark mode or not in your app by toggling the “Supports Dark Mode” build setting. For an example on how to dynamically switch between dark and light mode in your app using XAML, see the XAML ButtonStyling example project and the RequestedTheme property.

The XAML Control’s New Playground

William Yu — Tue, 10 Oct 2023 13:30:00 +0000

With the new XAML Control chooser window that is available in Xojo 2023r3 for Windows you can now play/experiment with XAML like never before, right in the IDE.

A Playground Built-In to the IDE

For those that have already tried the XAML Gallery example project, you may be familiar with one particular part of the demo which allows you to experiment with XAML in what we call the Playground:

This Playground has now been integrated into the Windows IDE in Xojo 2023 Release 3.

The New XAML Control Chooser Window

In Xojo 2023r2 we introduced DesktopXAMLContainer. Dragging one onto your layout and clicking on the edit icon allowed you to pick a pre-defined XAML control via our XAML Control Chooser Window. This XAML Control Chooser Window has now been updated in Xojo 2023r3 to include additional features that mimic what the XAML Gallery example project already provided, and that’s the Playground.

Experimenting in the New Playground

Just like in the XAML Gallery project, you can now enter your own custom XAML code and “run” it (using that play looking button next to the XAML editor).

When you are satisfied with how your XAML looks, just click Add to insert it into the DesktopXAMLContainer.

Et voilà! The new XAML Control Chooser Window provides a unique WYSIWYG interface that you can use to edit your XAML code and to experiment with XAML, now go out and play! Learn more about the the DesktopXAMLContainer in the Xojo Programming Documentation.