XAML – 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!

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.

Localizing XAML Controls in Windows Projects

Geoff Perlman — Wed, 16 Aug 2023 13:00:00 +0000

If you build desktop apps for Windows and wish to start using the new XAML-based controls via the DesktopXAMLContainer but aren’t sure how to localize those controls, here’s the solution:

Drag a DesktopXAMLContainer to a window.
Add the Opening event handler.
In the Opening event handler, create the XAML string that defines the control you want and concatenate in your localized constant.

Here’s an example of a simple button with a localized constant named Hello used to define the button text:

Me.Content = "

Notice that you can use single quotes for the the values. Which makes concatenating them via code easier.

If you’re not exactly sure what the right XAML code is, drag out a DesktopXAMLContainer, click on the Pencil icon on it and then choose the control you want and click the OK button. In the Inspector, you can now edit the Content property of your control to see what the XAML code is to create that control. You can then set the Content property in the Opening event (as described above) using that string.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

Introducing DesktopXAMLContainer

William Yu — Wed, 09 Aug 2023 13:30:00 +0000

For those developing on Windows, Xojo 2023r2 leverages the power of XAML to offer the ability to include WinUI controls alongside existing Win32 controls in Windows apps.

First, what is XAML?

XAML is a markup language based on an extension of XML which you can use to define your layouts that work with the DesktopXAMLContainer.

Can you show me an example of XAML?

Here is a simple example that creates a WinUI Button using XAML:

Note: XAML is case sensitive so

Doing More With DesktopXAMLContainer

William Yu — Wed, 09 Aug 2023 13:30:00 +0000

With the introduction of DesktopXAMLContainer you can slowly modernize your Windows apps or supplement your existing user interface with additional WinUI controls. If you are new to XAML, read my earlier post Introducing DesktopXAMLContainer to begin. In this tutorial I’ll demonstrate how you can do more with XAML.

Doing More With Layouts

While you can certainly add a single WinUI control in a DesktopXAMLContainer, you can also aggregate controls on the container to improve things. XAML makes it possible to customize the layout of your controls using mark-up instead of laying out your controls (one by one) on your window and adjusting the position by hand. Take for example a set of buttons that you want to layout vertically on your window. While you can certainly position three individual buttons on your layout, you could also accomplish this using one DesktopXAMLContainer with the StackPanel layout.

Without any dragging or dropping, you can re-configure this layout to be horizontal instead.

Handling Events

In the case of a single WinUI button in a DesktopXAMLContainer, handling events is a simple check in EventTriggered for the “Click” eventName. With multiple buttons in a DesktopXAMLContainer, you will want to properly Name them to determine which button was clicked.

You can inspect the parameters Dictionary to see what other Keys are available for a particular control and event. All controls will have at least the three basic keys: the fully qualified XAML Class name, the Name of the control, and the additional Tag property. Some controls will have additional Keys populated in the Dictionary, for example the XAML CheckBox control will fire a ValueChanged event with an IsChecked Key available in the parameters Dictionary. The specific names for these Keys can be found in the XAML Control Chooser Window.

Doing More With Code Behind

There will be instances where you may want to setup your control dynamically in code. The available properties/methods that a particular XAML control supports in the XAML Control Chooser window are documented. These properties and methods can be accessed using the DesktopXAMLContainer’s Value and Invoke methods. Let’s take the simple example of a Button. While you could set this all up using just XAML code, there may be times that you want to only change the caption of the Button in code. To do this you can use the Value method:

XAMLContainer1.Value("Content") = "My new caption"

Equivalently, you could also set this up using only XAML code:

XAMLContainer1.Content = "

If you have multiple Buttons in your DesktopXAMLContainer (like in our StackPanel example above), you can reference the control using a fully qualified name space:

XAMLContainer1.Value("Button2.Content") = "My new caption"

Conversely, if you wanted to know what the caption of Button3 is, you can use the Value to get it too:

myCaption = XAMLContainer1.Value("Button3.Content")

Some Properties/Methods Support Embedded XAML Code

If you take a look at the Button Content property, we’ve documented it with a note about it supporting XAML code. This means you can insert XAML code instead of just a basic string. So if you wanted to embed a ProgressRing inside a Button you could add that using the Content property.

XAMLContainer1.Value("Content") = ""

This would be the equivalent XAML code:

What is this winui namespace?

You may notice that some controls, added via the XAML Control Chooser window, use the winui namespace when you inspect the Content. Those particular controls are using the more modern UI look and feel. See https://learn.microsoft.com/en-us/uwp/api/microsoft.ui.xaml.controls
some controls offer the older style equivalent, see https://learn.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls
One such control is the ProgressRing. If you prefix this with winui, you’ll get the updated look, while the previous iteration can be seen without the winui prefix.

Custom Binding

Xojo supports a new mark-up syntax called {XojoBinding} specifically to help with re-usability of XAML controls. This currently only binds at the layout/IDE layer, but can be useful for re-usability purposes. As in this example you can customize the look of a Button by changing some properties in the inspector.

To set this up you will need to subclass a DesktopXAMLContainer and add the properties you want exposed in the inspector.

You will then need to add the necessary {XojoBinding} calls in the Content of your XAML:

The syntax for binding to a XAML property is written as:

{XojoBinding [name of class property]}

And in this case it’s binding the Caption property that we just added and exposed via the Inspector Behavior, to the Content of the XAML Button.

This means a change to the Caption property in the Inspector will now update the XAML code to reflect this change and update the layout accordingly. For doing more with the DesktopXAMLContainer, make sure to check out the Example Projects included in the Examples folder of the Xojo Download, the Xojo Documentation.

Accessing Windows Runtime (WinRT)

William Yu — Tue, 02 Jul 2019 10:00:02 +0000

During one of my sessions at XDC 2019 in Miami, I demonstrated the ability to access the Windows Runtime (sometimes abbreviated as WinRT) from within Xojo. For those not familiar with WinRT it is an application framework meant as a replacement for the decades old Win32 API (at least the non-GUI parts of it). Because WinRT is COM-based, and entirely unmanaged code, accessing it directly from Xojo is possible.

Note: this article assumes some prior knowledge of COM. Since WinRT was introduced in Windows 8, the example code listed here can only be run successfully on machines with Windows 8 or later.

While WinRT is COM-based, it does introduce some new types, like HSTRING, that are not normally seen when dealing with COM. Also, all WinRT classes inherit from the IInspectable interface, compared with other COM classes which either inherit from IUnknown or IDispatch. Another difference is that you will not be able to create the COM classes the traditional way (i.e. using CoCreateInstance). Instead, a new API was introduced (RoActivateInstance) that accomplishes the same task.

Determining the class name and unique identifier

If you’ve done anything with COM/ActiveX you know you’ll need the ProgID or CLSID in order to create the COM object. For example, this is seen when you add a COM/ActiveX control using the IDE’s Insert->ActiveX Component menu:

While the IDE shields you from some of these details, all this information lies open in the Registry, and thankfully all the WinRT classes do as well. To see a list of all the classes that are accessible you can open regedit and navigate to:

HKEY_LOCAL_MACHINE->SOFTWARE->Microsoft->WindowsRuntime->ActivatableClassId

For this example we’ll be accessing Windows.Globalization.Calendar

As mentioned, WinRT introduces some new types like HSTRING. We’ll need to create these HSTRINGs before we can call RoActivateInstance. These new APIs generally live in combase.dll so we can simply declare and call them in Xojo code:

Declare Function WindowsCreateString Lib "combase.dll" (source As WString, length As UInt32, ByRef out As Ptr) As Integer
Declare Function WindowsDeleteString Lib "combase.dll" (hstring As Ptr) As Integer
Declare Function RoActivateInstance Lib "combase.dll" (classId As Ptr, ByRef inspectable As Ptr) As Integer

Dim className As String = "Windows.Globalization.Calendar"
Dim classId As Ptr    // This is our HSTRING that is returned
Dim result As Integer = WindowsCreateString(className, className.Len, classId)

After we’ve setup the HSTRING, we can then call RoActivateInstance to create our WinRT class:

Dim inspectable As Ptr
result = RoActivateInstance(classId, inspectable)

Because all WinRT classes inherit from IInspectable you can iterate through all the available interfaces this class supports. For brevity I’ve determined that the Calendar interface’s unique identifier is “{CA30221D-86D9-40FB-A26B-D44EB7CF08EA}” so with this knowledge we can then query for this interface and start using it:

Dim unknown As New COM.IUnknown(inspectable)
Dim interfacePtr As Ptr

result = unknown.QueryInterface(COM.IIDFromString("{CA30221D-86D9-40FB-A26B-D44EB7CF08EA}"), interfacePtr)

Assuming all went well, we can start calling methods on the interface. This part of course requires intimate knowledge of what the interface supports along with the specific location of each method. Most of this information is stored in a type library, which we interrogate when building out COM classes added by the IDE using the Insert->ActiveX Component menu. Another strategy would be to simply look up the header or IDL file in the Windows SDK.

What an IDL file looks like

We do need some prior knowledge of the IUnknown and IInspectable interfaces to know how many methods deep one of these methods are (i.e. they each contain 3 methods each and since IInspectable inherits from IUnknown we can offset by 6). For this example we’ll invoke GetCalendarSystem (which lives 13 methods deep).

// Note: GetCalendarSystemFunc is a delegate with the
//       prototype as described in the IDL (converted to Xojo):
//       Func(this As Ptr, ByRef value As Ptr) As Integer

// The GetCalendarSystem function lives 13 methods deep, which means we offset
// by 12 * the size of a pointer to call the 13th method
Dim func As New GetCalendarSystemFunc(interfacePtr.Ptr(0).Ptr(12 * COM.SIZEOF_PTR))
Dim source As Ptr
result = func.Invoke(interfacePtr, source)

If result = COM.S_OK THen
    Declare Function WindowsGetStringRawBuffer Lib "combase.dll" (source As Ptr, length As Ptr) As WString

    Msgbox WindowsGetStringRawBuffer(source, Nil)
End If

You can download this example project here

The Win32 API may not be going away, but don’t expect it to be getting any additional love from Microsoft. The Windows Runtime (WinRT) is the future, but until Windows 7 becomes obsolete it is still a tough sell. While accessing WinRT from Xojo (or any Win32-based app) has been possible since it was first introduced, hosting UWP controls is another matter. Thankfully Microsoft has recently introduced some new APIs to do just that. If you’re interested in reading further about it, here are some articles:

XAML islands

Windows.UI.Xaml.Hosting docs