William Yu – Xojo Programming Blog

Custom Control Rendering with DrawControlInLayoutEditor

William Yu — Tue, 31 Mar 2026 15:22:00 +0000

One of the notable additions in Xojo 2026 Release 1 is that the DrawControlInLayoutEditor event is now available for Desktop and iOS/Android projects, giving you more possibilities over how your controls appear in the layout editor.

With this feature you can provide custom drawing for a control at design time, making it easier to visualize your UI without running the project.

If this sounds familiar, it’s because it brings Desktop and iOS/Android projects closer to what’s already possible in Web projects with WebSDKUIControl, where custom layout rendering has been available for some time.

Why this matters

Previously your custom Canvas controls would appear as generic placeholders, making it difficult to understand how they would look at runtime. Now you can:

Render a preview of your control directly in the layout editor
Display dynamic or state-based visuals
Make custom controls much easier to work with at design time

How it works

For Desktop projects, you can subclass DesktopUIControl and implement the DrawControlInLayoutEditor event. Your drawing code is executed by the IDE as it renders the control in the layout. For iOS and Android projects, this event is available on MobileUIControl.

You can also use this event directly with DesktopCanvas and MobileCanvas controls, so you can start drawing in DrawControlInLayoutEditor without needing to subclass anything.

This event gives you the flexibility to draw whatever you need—shapes, text, or even simplified representations of runtime content. For example, a custom media player control could display a play button and timeline, or a chart control could render a sample graph.

A note about XojoScript limitations

One important detail to keep in mind is that DrawControlInLayoutEditor runs using XojoScript. This allows the IDE to safely execute your drawing code at design time, but it also means not everything you’d typically expect to use in Xojo is available, especially when it comes to the graphics APIs.

In practice, most common drawing operations—such as shapes, lines, and text—work as expected. However, in some cases these graphics calls use a slightly different API, as is the case with LinearGradientBrush.

Also, because this runs as XojoScript, you cannot call other methods from within your DrawControlInLayoutEditorcode. To access your control’s properties, you’ll need to use the built-in ColorProperty, BooleanProperty, IntegerProperty, DoubleProperty, and StringProperty methods.

Support for more Graphics

In 2026r1, we’ve expanded the graphics capabilities available to DrawControlInLayoutEditor, building on what was previously supported for WebSDKUIControl. New additions include support for:

LinearGradientBrush, PictureBrush, and ShadowBrush
LineDash, LineDashOffset, LineCap, LineJoin, and MiterLimit
Outline
Scale, Rotate, and Translate
SaveState, RestoreState
Color constants (Red, Green, Blue, Yellow etc.)

Since XojoScript does not support the Pair type, the LinearGradientBrush API was adapted slightly:

Class LinearGradientBrush

  Sub Constructor()

  Sub AddStop(stop As Double, c As Color)

  Property StartPoint As Point
  Property EndPoint As Point

End Class

The main difference is how the brush is constructed and how stops are added, without needing Pair. With this new API, you can turn a basic graph into something much more visually appealing.

Turning off this feature

While many may prefer custom rendering for custom controls, it can become a bottleneck when a large number of controls are rendering content. If you prefer a less resource-intensive experience, you can disable this behavior in Settings → Layout by enabling the Static Rendering option.

Finally

With DrawControlInLayoutEditor now available for Desktop and Mobile projects, you can take advantage of the same benefits Web projects have enjoyed for years. Be sure to check out the new DrawControlInLayoutEditor example project, adapted from the WebSDK → CustomButton example. We hope you enjoy designing and previewing your custom controls with this new event—and yes, it also works in Libraries!

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.

Watchpoints in Xojo: A Smarter Way to Track Your Data

William Yu — Tue, 31 Mar 2026 13:22:00 +0000

Debugging isn’t just about stepping through code anymore, it’s about understanding how your data behaves over time. With the new watchpoints feature in Xojo, you can now monitor variables and object properties more intelligently, without constantly stepping line by line or adding logging just to see when values change.

What Are Watchpoints?

Watchpoints let you pause execution when the value of a variable or property changes. Instead of asking “how did I get here?”, watchpoints help you answer “when did this change?”

This is especially useful when:

A value is being modified unexpectedly
Multiple parts of your code interact with the same object
You’re tracking down subtle state-related bugs

How Watchpoints Work

Setting up a watchpoint requires pausing execution where you would like to start monitoring the variable or property of an object.

In this example, we want to monitor the count variable, so you can right-click it in the variables debugger list and select Watch from the context menu. Once a watchpoint is set on a variable or property, the debugger keeps track of its value during execution. When the value changes, execution pauses and shows the line that triggered the change. Notice that the watchpoint break line is highlighted differently from the current execution line, and a Watchpoints list is now displayed.

This gives you immediate visibility into:

What code caused the modification
What the previous and new values are
What the surrounding state looks like

Why This Matters

Traditionally, tracking down a value change required manually stepping through code or adding temporary logging. Both approaches are time-consuming and error-prone.

Watchpoints eliminate that friction by:

Reducing the need for repetitive stepping
Highlighting only meaningful changes
Letting you focus on the root cause faster

Conditional Watchpoints

Watchpoints in Xojo aren’t limited to triggering on every change—you can make them conditional. For example, you can break only when a value is equal to, greater than, or less than a specific threshold, or even when it falls within a defined range. For string, both case-sensitive and case-insensitive comparisons are supported. This makes it much easier to focus on the changes that actually matter, especially when a variable updates frequently but only becomes problematic under certain conditions.

To add a condition to a watchpoint, right-click the watched variable or property and choose Edit Watchpoint Expression from the context menu.

The expression editor adapts based on the type of variable or property you’re watching, providing hints about what values and conditions you can enter.

Handling Object Lifetimes

One important detail when working with watchpoints is object lifetime.

If a watchpoint is attached to a property of an object that goes out of scope or is destroyed, the debugger can no longer track it. In these cases, Xojo provides feedback through the Messages pane so you know the watchpoint is no longer valid, along with the last known value.

What works and what doesn’t

You can set watchpoints on most variables and properties, even variants; however, Arrays, Structures, and computed properties are not supported. Code within #pragma DisableBackgroundTasks or #pragma Debug False blocks will not trigger watchpoint breaks. Watchpoints are also not currently available for Android projects.

Final Thoughts

Watchpoints bring a new level of precision to debugging in Xojo. Instead of chasing bugs through code, you can now let the debugger do the work of tracking down exactly where things go wrong.

Give them a try in your next debugging session—you might find yourself solving problems faster than ever!

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.

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!

Windows Barcode and HTMLViewer Updates

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

The Barcode Scanner received a significant upgrade in Xojo 2025r2 on Windows, with support for more aspect ratios and video mirroring. The DesktopHTMLViewer also saw improvements with the ability to print to PDF.

Consistent Barcode Scanning Experience

Not to be outdone, the Barcode scanning experience on Windows has been brought up to par with other platforms, now including support for video mirroring in the scanning window. Also, if you were seeing a “squished” video before, we’ve now added support for a wider range of video devices and aspect ratios.

DesktopHTMLViewer Improvements

Thanks to some feedback we received, the DesktopHTMLViewer now supports raising the FocusReceived, FocusLost, KeyDown, and KeyUp events.

While DesktopHTMLViewer.Print works well, there are times you might want to go straight to PDF. If you’d rather skip the default print prompts, you can now use the new DesktopHTMLViewer.PrintToPDF(file As FolderItem) method to print HTML content directly to a PDF file. Just pass in the destination file and everything else works just like the regular Print method, including the PrintComplete event firing on success.

We’re always working to make Xojo better, and your feedback plays a big part in that. So from all of us here at Xojo—thank you! We truly appreciate your input as we continue to improve the product for you and everyone who uses it.

Windows ICU Changes

William Yu — Tue, 25 Mar 2025 15:33:53 +0000

For many years, Xojo included prebuilt ICU libraries (International Components for Unicode) on Windows to ensure consistent Unicode behavior across platforms. However, maintaining and updating ICU manually required rebuilding it with each release, and users wouldn’t receive updates unless they updated Xojo itself.

With Windows 10 version 1703, Microsoft introduced built-in ICU support, allowing applications to use the system provided ICU instead of bundling their own. By leveraging this, Xojo now benefits from automatic updates, a reduced app footprint, and improved compatibility with the latest Unicode and locale data.

Which parts of the framework use ICU?

One of the main areas where ICU is used is the DateTime class, which includes Locale and TimeZone support. This helps with formatting dates and times and handling timezone differences reliably. ICU is also used for number formatting and string manipulation, particularly when working with characters like emojis and other complex Unicode symbols.

What benefits can be observed?

Fewer DLLs
45MB smaller app sizes
Faster execution times, i.e. DateTime.Now is roughly 10% faster
Daylight saving time no longer requires a rebuild of your Xojo app

What are the new requirements?

As mentioned, Windows began including prebuilt ICU libraries starting with Windows 10 version 1703, so your apps won’t run on earlier versions. However, if you’re using Windows Server 2019, you’ll need to be on at least version 1809.

Conclusion

By shifting to Windows’ built-in ICU libraries, Xojo has eliminated the need for manual ICU updates and reducing app file sizes. This change means your apps will always have the latest updates for date/time, locale, and character handling, thanks to Windows updates.

Xojo IDE on Pi: A Game-Changer in Embedded Development

William Yu — Tue, 25 Mar 2025 15:33:47 +0000

Prior to Xojo 2025r1, Raspberry Pi developers had to rely on a two-step process: programming on a separate computer that could run the Xojo IDE, then either remotely debugging the app on the Pi or manually copying the executable over. While this worked, it added extra steps and potential complexities, especially when dealing with debugging and deployment.

Introducing the Xojo IDE for Linux ARM64

8GB Raspberry Pi 5, running Bookworm

With the release of Xojo 2025r1, however, everything has changed. Now, for the first time, developers can run the Xojo IDE directly on their Raspberry Pi 64-bit device. This means you can write, build, and test your applications all from within the same environment. The seamless integration allows for faster iteration and a smoother workflow, giving you more control over your development process. Not only can you now run the Xojo IDE on a Pi, but also on any Linux ARM64 distro.

What is Supported?

Nearly all the features you love about working in the Xojo IDE on other platforms are now available with the Linux ARM64 IDE, with the exception of building macOS and Mobile (Android/iOS) apps. Instead of remotely debugging your Raspberry Pi app using the Xojo IDE on Windows, you can now remotely debug your Windows app using the Xojo IDE on Pi!

For best results, we recommend a Raspberry Pi 5 or 500 with 8GB of RAM.

Xojo Loves Pi!

With the Xojo IDE now available for Linux ARM64, we’re making our case as the go-to solution for Raspberry Pi developers. The simplicity, cross-platform support, and power makes Xojo an attractive choice for those looking to build apps on the Pi, without the complexity of traditional programming environments.

NOTE: You can build Linux apps with Xojo for free, no license required. Just select Linux in Build Settings, then choose ARM or x86 architecture in the Inspector.

Dragging to More Destinations

William Yu — Tue, 25 Mar 2025 15:33:28 +0000

It’s been a common complaint that on macOS you could not get the Destination of a FolderItem drag. That was then, but this is 2025r1 and now dragging finally knows where it’s going, and it’s happy to reveal its Destination!

The History

While we’ve offered an API to get the Destination of a DragItem, it has been returning Nil on macOS for quite some time. In fact, it likely hasn’t worked since our transition from Carbon to Cocoa way back in the day. Amid all the API changes that came with that transition, DragItem.Destination was unfortunately left behind.

A New Way to FolderItem Drag

To avoid breaking existing code, we chose not to overhaul our entire drag-and-drop system just to support this feature. Instead, we’ve made a few simple additions that are necessary to get FolderItem drags to return a valid DragItem.Destination

Here’s how a FolderItem drag would currently be setup (for example in the DesktopWindow.MouseDown event):

Var fileToCopy As FolderItem = SpecialFolder.Temporary.Child("Test")
Var item As New DragItem(Self, 0, 0, 100, 100)
item.FolderItem = fileToCopy
item.Drag

After dropping the item at its Destination, checking item.Destination would always return Nil:

If item.Destination = Nil Then
    MessageBox "Not a happy destination. 😔"
End If

By making one simple addition and using the RawData API, we can now initiate FolderItem drags in a way that correctly returns a valid FolderItem.Destination.

Var fileToCopy As FolderItem = SpecialFolder.Temporary.Child("Test")
Var item As New DragItem(Self, 0, 0, 100, 100)
item.FolderItem = fileToCopy
item.RawData("public.file-url") = ""
item.Drag

Now, when you check the Destination after the drag is complete, you’ll receive something much more meaningful:

If item.Destination <> Nil And item.Destination IsA FolderItem Then
    MessageBox(FolderItem(item.Destination).NativePath)
End If

An Added Benefit

While this change is a big improvement, why stop there? In the past, you could only drag FolderItems to the Destination, and the entire contents of that FolderItem would be copied over. With the addition of this new dragging method, you can now assign content to RawData("public.file-url"). Instead of copying the entire FolderItem to the Destination, we’ll copy the content from the RawData instead.

Here’s how you could set it up:

// The fileToCopy does not need to exist, we'll simply
// pull the file name from it and create the file at
// the destination with the new content that is assigned
// to the RawData.
Var fileToCopy As FolderItem = SpecialFolder.Temporary.Child("DummyFile.txt")
Var item As New DragItem(Self, 0, 0, 100, 100)
item.FolderItem = fileToCopy
item.RawData("public.file-url") = "Content that will be written to the destination file."
item.Drag

Conclusion

With these enhancements, dragging FolderItems on macOS has become more flexible and powerful than ever. Not only can you now easily retrieve a valid Destination, but you also have the power to control the content being copied, thanks to the integration with the RawData API.

So, go ahead—drag that FolderItem and show us your destination!

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!

Sharpening Our Preemptive Threads

William Yu — Tue, 10 Dec 2024 16:36:50 +0000

In Xojo 2024r3.1 we introduced the highly requested preemptive threads feature. This new thread type enables true independent execution of code, separate from the main thread or any other threads, allowing full utilization of all CPU cores. Let’s explore some of the improvements we’ve made since adding this capability.

Protecting Our Objects

Xojo objects are uniquely constructed and reference counted, a detail most users don’t need to think about. However, when working with preemptive threads, objects inherently require special protection. In Xojo 2024r3.1, we implemented safeguards to enable the use of objects in preemptive threads, but the approach wasn’t as efficient as it could be. Operations like passing objects as parameters or assigning them as properties incurred overhead, and those costs added up.

As uniquely as our objects are to construct, they also required a unique approach to protect them. In Xojo 2024r4 we updated how we protect our objects so that this operation happens much faster, improving the overall experience when running preemptive threads.

For an example of these efficiencies, check out this forum post where users benchmark the One Billion Row Challenge.

Uniquely Destructed Objects

As mentioned, our objects are uniquely constructed, and this uniqueness extends to their destruction as well. When a preemptive thread is running, it’s important not to wait for other objects to be destructed within the Destructor method.

Sub Object1.Destructor()
  While Object2 <> Nil
    // Waiting for Object2 to be destructed can lead to a deadlock,
    // especially if Object2 is being destructed from a separate thread.
  Wend
End Sub

Also, avoid situations where you are creating new objects while in the Destructor and referencing Self.

Sub Object1.Destructor()
  // Referencing Self in a new object will lead to a
  // recursive Destructor sequence causing a dead lock.
  Var newObj As New Class1
  newObj.NotAGoodIdea = Self
End Sub

Handling Race Conditions

In Xojo 2024r3.1, we created an example demonstrating how to synchronize shared resources using critical sections and semaphores. This example also highlights the effect of a race condition: your app will crash immediately, terminating the debugging session with no indication as to where the crash may have occurred.

These access violations were never caught by our debugger until now. Because these crashes may interfere with what can be displayed in the debugger, we’ve intentionally limited what is shown, as the access violation could leave the app in an unstable state. Although these access violations are not exclusive to crashes caused by race conditions, this new feature aims to help you identify potential race conditions in your apps when working with preemptive threads. Let’s take a look at that example and see what happens now when you run it through the debugger:

When you click the button designed to intentionally crash the app, you’ll now be returned to the debugger, where you’ll see a new crash icon. This symbol indicates that a crash has occurred, and the app cannot proceed further (which is why all debugging step commands are disabled, and the debugger values are not loaded so objects will be Nil). Your only options at this point are to stop the app or attempt to reload the debugger values.

Clicking the command button on the left refreshes or reloads the debugger values. If the app is stable enough, the debugger values will refresh; otherwise, the app may terminate automatically at this point.

In summary, these improvements aim to make working with preemptive threads more enjoyable by offering both enhanced speed and an easier process for identifying potential race conditions, which was previously much more challenging. Like the One Billion Row Challenge, we’re eager to hear about all the ways you’re making use of preemptive threads in your own apps!

Cooperative to Preemptive: Weaving New Threads into your Apps

William Yu — Tue, 01 Oct 2024 15:31:59 +0000

Our latest Xojo update introduces a new thread type that maximizes the potential of your multi-core systems. This new preemptive thread model enhances efficiency and responsiveness, allowing for improved multitasking and resource management while delivering significant performance gains. In this post, we’ll explore the benefits of this upgrade, delve into the implementation details, and guide you on how to fully utilize the new preemptive threading capabilities.

Threading Models

Cooperative Threads: This is the threading model that Xojo has traditionally supported and continues to offer. In this model, threads must voluntarily yield control at specific points that we define. This ensures that most operations in Xojo code are thread-safe, as we manage access to MemoryBlocks, Arrays, etc. However, this approach can lead to inefficiencies if a thread fails to yield, potentially blocking UI, and because only one thread runs at a time, it doesn’t fully utilize multiple cores or truly run in parallel.

Preemptive Threads: Introduced in Xojo 2024r3, this new thread type allows threads to be interrupted at any point, enhancing responsiveness and fully utilizing multiple cores. While this model provides significant performance improvements, it also introduces new challenges. Because threads can be interrupted at any time, you’ll need to be more diligent about locking resources, such as MemoryBlocks and Arrays, to avoid potential race conditions.

Using Preemptive Threads

We’ve added a new Thread.Type property that allows you to switch your threads to the new preemptive thread model, here’s how you can start one up:

Thread1.Type = Threads.Types.Preemptive
Thread1.Start

You can set this property either before starting your thread or while the thread is running. However, if changing it while the thread is active, it must be done safely from within the running thread itself, and not externally.

Event Window1.Opening
  // Start the thread and setup the type in the Run event instead
  Thread1.Start
End Event

Sub Thread1.Run
  Me.Type = Threads.Types.Preemptive
  // Run a very long process preemptively.
  newMemBlock = memBlock.Compress
  
  Me.Type = Threads.Types.Cooperative
  // Switching to cooperative mode and modifying a shared array safely.
  mySharedArray.Add("New item")
End Sub

Concurrency and Synchronization

As mentioned earlier, cooperative threads avoid many of the issues that arise with preemptive threads, since we control when thread switching occurs. With preemptive threads, however, you can no longer safely modify things, like shared arrays, the same way you could before with cooperative threads. To manage this, you’ll need to use tools like CriticalSections and Semaphores more frequently to protect your shared resources.

The challenge lies in efficiently supporting both threading models while enabling the main thread to synchronize with either type. To address this, we’ve added a new Type property to CriticalSection and Semaphores, which must match the thread type you’re using to protect shared resources.

// Imagine the main thread and two additional threads all trying to access a Dictionary simultaneously.
Sub RunTest
  Thread1.Type = Thread.Types.Preemptive
  Thread2.Type = Thread.Types.Preemptive

  CSLock = New CriticalSection
  // Since we are using this CriticalSection in preemptive threads,
  // the synchronization type must be compatible.
  CSLock.Type = Thread1.Type

  Thread1.Start
  Thread2.Start

  Do
    CSLock.Enter
    MyDictionary.RemoveAll
    CSLock.Leave
  Loop
End Sub

Sub Thread1.Run
  Do
    CSLock.Enter
    MyDictionary.Value("Random1") = Rnd
    CSLock.Leave
  Loop
End Sub

Sub Thread2.Run
  Do
    CSLock.Enter
    MyDictionary.Value("Random2") = Rnd
    CSLock.Leave
  Loop
End Sub

What things are thread-safe?

We’ve updated our framework to safeguard areas that were previously not preemptive thread-safe. For the most part, our entire framework is now safe for concurrent use with preemptive threads, with a few exceptions like XojoScript and Runtime.IterateObjects. When sharing resources such as MemoryBlocks, Dictionaries, or Arrays among threads, you may need to use CriticalSections or Semaphores to ensure safe access. However, if you’re only reading from these resources without modifying them, synchronization is not required. You’ll be happy to know that calling Thread.AddUserInterfaceUpdate from a preemptive thread is also safe.

Performance Considerations

With the ability to switch your threads to preemptive, there are some performance factors to consider. While running 100 threads at once might seem appealing, it often leads to over-utilizing your system’s resources. For optimal efficiency, it’s best to limit the number of threads to match the number of available cores. To assist with this, we’ve introduced the new System.CoreCount, which helps you determine the number of cores on your system.

While Xojo’s framework doesn’t shield you from every potential issue, we do handle synchronization for key operations like object creation and destruction. However, you may notice these actions are slower in preemptive threads due to the extra synchronization required.

Usage and Examples

There’s no question that preemptive threads offer significant advantages, and when used correctly, they can greatly enhance your app’s performance. Check out our threading example projects included with the 2024r3 release to see preemptive threads in action and enjoy weaving these new threads into your future apps!

A special thanks to our MVPs for their invaluable help in refining and testing this new feature! Be sure to check out the new ThreadPool example for some practical, real-world use cases and read MVP Kem Tekinay’s blog post Preemptive Threads Are Here and They Are …. Pretty Good.

Need More Information? Read more about preemptive threads in the Xojo Documentation and Blog. Or read about Semaphore and CriticalSection.

Fuzzy Searches with SQLite’s SOUNDEX

William Yu — Tue, 01 Oct 2024 15:31:15 +0000

Though a minor update, Xojo now offers access to another core SQLite function: SOUNDEX.

What is SOUNDEX?

SOUNDEX is a core function in SQLite that encodes a string into a 4-byte sequence, enabling indexing based on pronunciation. While the technical details of the algorithm are available on Wikipedia, the gist is that SOUNDEX(“Smith”) will match SOUNDEX(“Smythe”), making it useful for large searches to identify different spellings of the same term.

How is it used?

For the curious, you can see how words are indexed by simply invoking a select on a SOUNDEX term:

Var db As New SQLiteDatabase
db.Connect

Var rs As RowSet
rs = db.SelectSQL("SELECT SOUNDEX('Smith')")
Var smith As String = rs.ColumnAt(0).StringValue
rs = db.SelectSQL("SELECT SOUNDEX('Smythe')")
Var smythe As String = rs.ColumnAt(0).StringValue

Running this you’ll notice that ‘Smith’ and ‘Smythe’ both return the same SOUNDEX 4-byte sequence of “S530” — Here’s a quick breakdown of how this was generated:

First Letter (S): The first letter of the name stays the same, so “S” from the name “Smith” or “Smythe” becomes the first character in the code.
Numbers (530): The remaining characters in the code represent the sounds of the next letters in the name. Each number is based on a group of similar-sounding consonants:
- 5 = “M” (because M sounds like “M” in “Smith” or “Smythe”)
- 3 = “T” (because T sounds like “T” in “Smith” or “Smythe”)
- 0 = No sound match or a vowel, so it acts as a filler to complete the 4-character code.

Practical Use Case

With a better understanding of the algorithm, we can put it to practical use by searching our database for names that sound similar to “Smith.”

db.ExecuteSQL("CREATE TABLE contacts(id INTEGER PRIMARY KEY, name TEXT)")
db.ExecuteSQL("INSERT INTO contacts (name) VALUES ('Smith'), ('Smythe'), ('Simith'), ('John')")

rs = db.SelectSQL("SELECT name FROM contacts WHERE SOUNDEX(name) = SOUNDEX('Smith')")

// Expected to find 3 names: Smith, Smythe, and Simith
Var namesFound As Integer = rs.RowCount

The Fuzzy Conclusion

Because the SOUNDEX algorithm is designed around English pronunciation patterns, it may not work as well for languages with different sound structures or alphabets, so results may vary depending on the language. It’s also worth noting that this feature is available for all targets, except Android at this time.

New Database Connections

William Yu — Wed, 26 Jun 2024 15:00:00 +0000

While Xojo has always supported adding database connections, the old method was far from ideal. Let’s delve into the improved approach using the new Database Connection project items and explore some recent additions to our database API.

Out With The Old

The old database connections were quite limiting, requiring you to create a new connection and re-enter all the parameters whenever one changed. With our new Database Connection items, you can now easily update specific connection parameters directly in the inspector.

Additionally, you can now choose whether the item will auto-connect or if you prefer to connect to it later in your code.

Connecting to a Specific Database

There are times when you need to connect to a database for debugging and testing, but for the final builds, you want to connect to your production database/server. Setting this up correctly with the old database connection method required creating two separate connection items—one for debug and one for release. With the new Database Connection items, this process is much simpler and fits more easily into the build process. You now have several new Database Connection subitems that can be customized based on the stage of your build. These subitems are linked to the Stage Code in your Shared Build Settings, ensuring that when you build a final release, your database connection uses the correct settings automatically.

Additional Database Features

In addition to this change, there are two new database APIs that may be useful to you:

A new method, IsConnected, has been added to the SQLiteDatabase, ODBCDatabase, PostgreSQLDatabase, and MySQLCommunityServer classes. This method returns true if the connection is still active, and false if it is not.
We’ve enhanced Database.AddRow with a new signature that returns the unique ID of the newly inserted row. This feature is supported for SQLiteDatabase, ODBCDatabase, PostgreSQLDatabase, and MySQLCommunityServer classes. It is recommended to use this new API instead of the deprecated SQLiteDatabase.LastRowID and MySQLCommunityServer.LastInsertedRowID

Let’s explore how the new Database.AddRow feature can assist you. Previously, only SQLiteDatabase and MySQLCommunityServer had APIs to retrieve the unique ID of the last inserted row. Now, PostgreSQLDatabase and ODBCDatabase also have this capability by using the new Database.AddRow(tableName As String, row As DatabaseRow, idColumnName As String = "") As Integer

The new aspect of this signature is the idColumnName parameter and the return value. For databases that support the SQL RETURNING clause, the idColumnName specifies the column whose value will be returned. For databases that do not support the RETURNING clause, we will use the suitable method for each specific database to return a unique value.

We recognize the significance of databases in your Xojo apps. So with these updates to database connectivity for your desktop, web and console apps, and the addition of new features, we aim to make your database programming easier and more efficient.

Enhanced Emoji Support: A Look into Graphics and String.Character Improvements

William Yu — Wed, 26 Jun 2024 15:00:00 +0000

In the past, people used a two-character symbol : ) to add a smiley to their messages. Nowadays, we have full-color emojis for that purpose, so it’s time for Xojo to catch up unless we want to be seen as old .

Enhanced Emoji Rendering

While Xojo’s Graphics class supported rendering emojis on Windows and Linux, their appearance was less appealing.

Now in Xojo 2024r2, we’ve enhanced emojis with vivid colors!

You’ll notice that other parts of the Xojo framework that utilize the Graphics class, such as the ListBox, have also benefited from this update.

Understanding Emojis at a Deeper Level

Understanding how emojis are encoded is crucial for grasping how Xojo’s String type works and how we interpret them. Any text or emoji displayed on the screen can be considered a Unicode sequence or a series of Unicode sequences. At a deeper level, a single Unicode sequence can be constructed from multiple Unicode code points (i.e., bytes of data). For clarity, we’ll describe one character (whether simple text or an emoji) as being composed of Unicode sequence(s).

To demonstrate, let’s try to understand the woman

This particular woman is not very complex, it is made up of one single Unicode sequence (with corresponding code points). Our String type can easily handle this one Unicode sequence and reports correctly that the Length of the String is 1 (even though the entire emoji is made up of 4 bytes of code points).

Now let’s take a look at a more complicated woman

The only difference visually is that this woman has fiery red hair. This subtle change in appearance means that to construct this emoji requires not 1, not 2, but 3 distinct Unicode sequences (with a grand total of 11 bytes of code points).

Note that the reported length of the String is 3 Unicode sequences, even though we visually see only one character. This distinction is very important in understanding how String functions work. Xojo’s String functions inherently deal with Unicode sequences, not individual characters. When you do need to work with complex emojis like these, you will want to utilize our String.Characters API which effectively manages this complexity.

An Optimized String.Characters

Given the prevalence of emojis in everyday text and messages, properly handling them within Xojo’s String type is crucial. While we initially introduced this feature as String.Characters, it functioned as an iterator until Xojo 2024r2. Now, String.Characters returns a String array, which can still be iterated, ensuring existing code continues to work as before. Additionally, this update offers the added advantage of significantly improved speed, especially on Windows and Linux. Along with this update, we introduced String.CharacterCount, which is useful when you need to know the number of characters in a string without storing them all in an array.

To further understand emojis and their corresponding Unicode sequences, check out this Full Emoji List.

Don’t throw that Pi into the garbage

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

The most recent iteration of Pi, operating on the Bookworm OS, may cause Xojo’s DesktopHTMLViewer to appear like garbage, but that’s no reason to discard either the Pi or Xojo!

If you’re encountering display anomalies with the DesktopHTMLViewer on a Pi 5 running Bookworm OS, rest assured you’re not alone. This issue stems from the version of WebKitGTK the DesktopHTMLViewer relies on. While efforts to address this persist, a viable workaround exists: disabling hardware acceleration when utilizing WebKitGTK. Fortunately, in Xojo, we’ve facilitated this by exposing an environment variable. You can conveniently set this variable before the creation of the DesktopHTMLViewer, such as within your App.Opening event.

To turn hardware acceleration OFF, you can assign that to the WEBKIT_HARDWARE_ACCELERATION environment variable:

System.EnvironmentVariable("WEBKIT_HARDWARE_ACCELERATION") = "OFF"

By default, hardware acceleration is enabled/disabled as requested by web contents, but you can also force hardware acceleration to be enabled even for websites not requesting it:

System.EnvironmentVariable("WEBKIT_HARDWARE_ACCELERATION") = "ON"

To revert it to its default state, simply assign any value other than ON/OFF. While we remain optimistic that this issue will be resolved at some point, in the interim, this environment variable stands ready to function as a temporary solution.

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.

Small and Simple Changes to Speed Up the Xojo IDE

William Yu — Tue, 12 Dec 2023 14:30:00 +0000

At times, we encounter minor yet impactful changes stemming from seemingly uncomplicated issues. In specific instances, addressing these modest complexities may necessitate minimal adjustments, yet yield substantial outcomes.

Optimizing the Navigator

In Xojo 2023r4 we tackled a performance issue impacting the navigator’s speed, particularly during scrolling. Upon closer examination, we identified that the substantial consumption of resources and time was attributed to the rendering of these basic and compact navigator icons.

What was initially intended as a straightforward drawing of an icon, ended up becoming a needlessly intricate element that significantly impeded overall speed.

The Before and After

In 2023r3, a noticeable lag occurs during scrolling, with the thumbtrack failing to keep pace with the mouse movement.

In 2023r4, scrolling has been significantly improved and the thumbtrack now maintains synchronization with the mouse movement, resulting in a smoother experience.

What other benefits does this change offer?

Having pinpointed the root cause of this issue, we proceeded to implement updates across various instances where the needless drawing persisted. We identified a similar occurrence when rendering command bar icons affecting every keystroke in the code editor and movement in the layout editor. Refactoring this aspect is expected to enhance performance in these specific areas of the IDE. We trust that you will find the IDE more enjoyable following these small and simple changes.

Time to Reflect on Stack Optimization

William Yu — Tue, 12 Dec 2023 14:30:00 +0000

As the year draws to a close, it’s a fitting moment to pause and contemplate for a minute. Oh, my apologies, in Xojo 2023r4, my contemplation time has been decreased to a swift 30 seconds. Let me make the most of that time to reflect instead…

Overflowing with Gratitude

Our stacks are overflowing with appreciation. Appreciation for not being overworked that is. That’s what they have been doing, being overworked in Xojo 2023r3 and slowing things down. In 2023r4, we have optimized our stack overflow checks to reduce the unnecessary effort expended on this task. This optimization will be especially valued by macOS users, as our stack overflow checks consumed the most time on that platform. Take for example, how many more functions calls can be made in 2023r4 over 2023r3 in just one second:

Var start As Integer = System.Ticks
Var count As Integer
While System.Ticks - start < 60
  Reflect("Thanks")
  count = count + 1
Wend

MessageBox count.ToString + " functions calls in one second"

In 2023r3, we can Reflect (“Thanks”) 1236484 times in one second.

However, in 2023r4 we can Reflect twice as many times, over 2777000 times! That’s a lot of Reflection.

Appreciation for our Users

It would be unjust not to recognize the assistance we’ve received from our users, particularly those who consistently report issues for us to address. A special acknowledgment goes out to those who go the extra mile in helping us pinpoint problems and offer valuable tips and solutions. You know who you are, and we sincerely appreciate your contributions!

Using the Zip & Unzip Feature

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

FolderItem has been extended with new methods to Zip and Unzip files and folders in Xojo 2023 Release 3. Take a peek as we look at how easy it is to use this new feature.

What is New?

Xojo 2023r3 adds new FolderItem.Zip and FolderItem.Unzip methods with support for the most widely used DEFLATE compression format.

Zip(destination As FolderItem, contentsOnly As Boolean = False, compression As ZipCompressions = ZipCompressions.Normal) As FolderItem

Zip(contentsOnly As Boolean = False, compression As ZipCompressions = ZipCompressions.Normal) As FolderItem

Unzip()

Unzip(destinationFolder As FolderItem)

How to Zip

Here’s an example of zipping SomeFolder on your Desktop:

Var someFolder As FolderItem = SpecialFolder.Desktop.Child("SomeFolder")
Var outputFile As FolderItem = someFolder.Zip

The outputFile will be created on your Desktop with the name “SomeFolder.zip”.
This zip file will contain a single folder called SomeFolder, along with the contents of that folder.

+- SomeFolder.zip
  +- SomeFolder
    +- File1.ext
    +- File2.ext
    +- etc.

If you’d rather just zip up the contents of SomeFolder then you can pass True to the contentsOnly parameter.

Var outputFile As FolderItem = myFolder.Zip(True)

Now the zip file only contains the contents of the SomeFolder folder.

+- SomeFolder.zip
  +- File1.ext
  +- File2.ext
  +- etc.

Note: on macOS, when the OS unzips this kind of zip folder hierarchy, it will automatically create a folder with the contents, regardless of what the actual zip hierarchy looks like. However, this does not affect our own FolderItem.Unzip method.

With the overloaded Zip method that takes a destination FolderItem, you can use this to specify where the zip file is created.

Var destinationFolder As FolderItem = SpecialFolder.Documents
Var outputFile As FolderItem = myFolder.Zip(destinationFolder)

In this case the outputFile is created in the user’s Documents folder. If you wanted to rename it to something other than the default name with a “.zip” appended to it, you can also use this syntax to pass a destination file instead of a destination folder.

Var destinationFile As FolderItem = SpecialFolder.Desktop.Child("MyZipFile.zext")
Var outputFile As FolderItem = myFolder.Zip(destinationFile)

While we only demonstrated how to zip a folder in these examples, the exact same syntax applies for zipping a single FolderItem file too.

How to Unzip

Conversely, if you wanted to unzip a file, this is a simple call to FolderItem.Unzip

outputFile.Unzip

This unzips the outputFile contents to the same directory that the outputFile resides in. If you wanted to unzip the contents to a different location, pass in a destination folder instead:

outputFile.Unzip(SpecialFolder.Temporary)

This feature is not yet supported in Android. In conclusion, Zipping/Unzipping has never been easier! Learn more in the Xojo Programming Documentation – Zip and UnZip. (Thanks in part to zlib)

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.

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.

Linux Joins the Dark Side

William Yu — Tue, 13 Dec 2022 14:33:00 +0000

While we’ve been hard at working getting Linux ARM 64 support ready for Xojo 2022r4, released earlier today, we also updated Xojo’s Linux support for Dark Mode. Color.IsDarkMode now functions properly and our Linux IDE has now officially joined the dark side.

Depending on your flavor of Linux (in this example we’re using Gnome on Ubuntu 20.04), you can change themes from your Settings/Appearance sidebar:

And for those interested in other themes, you can also change themes at the command line:

gsettings set org.gnome.desktop.interface gtk-theme 'Yaru-dark'

Xojo will be able to determine which themes are dark mode savvy. Now you are ready to enjoy the dark side of Linux along with Xojo!

Improving Multi-Monitor Support on Windows

William Yu — Wed, 12 Oct 2022 13:46:15 +0000

The Bug Bash was good at bringing back to our attention some older bugs. One such issue was multi-monitor support with mixed scale factors on Windows. While supporting 2 monitors at different scale factors worked for the most part, anything beyond that was flawed.

Why is this even a problem?

In Xojo our coordinates (Left, Top, Width, Height, etc.) are in points. On Linux and macOS the underlying system APIs that we use also treat coordinates as points. However, on Windows we are still left using APIs that deal with pixels. This meant writing our own Pixel to Point (and vice versa) conversion functions for moving/sizing, along with a system to mimic how Windows finds the best monitor for a Window based on it’s size/location, but in points.

A Warped Brain

To be honest, thinking about more than just 2 monitors with mixed scaling became a serious spatial issue. I had to draw this to envision what needed to be done.

Last, but not least, we needed to test this. So after a quick run to the store, I picked up this little adapter and voila, a fix was born!

To read more about the issues addressed here, see:
https://tracker.xojo.com/xojoinc/xojo/-/issues/54369
https://tracker.xojo.com/xojoinc/xojo/-/issues/69125