First, I’m going to create a headless desktop application. A console application would work, but shows a command box.

In the Xojo IDE, create a new desktop project and delete Window1 and MainMenuBar. Then add the Opening Event Handler to App and add this code:

Self.AllowAutoQuit = True

This will allow the application to quit when done.

Add the DocumentOpened Event Handler to App and add this code:

If item _ ' Using item
 .NativePath _ ' property NativePath
 .NthField(":", 1) <> "AlertDemo" Then ' Compare the value left of the ":"
 Return ' If invalid return (quit)
End If
Var alert As String ' Define the variable
alert = item _ ' Using Item
 .NativePath _ ' property NativePath
 .NthField(":", 2) ' Extract the contents to the right of the ":"

alert = DecodeURLComponent(alert) ' Convert the content to plain text
MessageBox(alert) ' Show the alert
' The app will now quit

To test you can select Shared in Build Settings.

And enter a value into Command Line Arguments:

Running the app in debug mode will show:

Now build the project and create an installer using Inno Setup.

[Setup]
AppId={{B4D9ABDA-9F58-4FE0-A5F3-3E39C28EAB59}
AppName=Alert Demo
AppVersion=1.0
DefaultDirName={commonpf64}\Axis Direct Ltd\Alert Demo
DefaultGroupName=Axis Direct
OutputDir=C:\Xojo Projects\Alert Demo\Installer
OutputBaseFilename=AlertDemoInstaller
Compression=lzma
SolidCompression=yes
ChangesEnvironment=yes
[Languages]
Name: "english"; MessagesFile: "compiler:Default.isl"
[Tasks]
[Dirs]
Name: "{app}\Alert Demo Libs"
[Files]
Source: "C:\Xojo Projects\Alert Demo\Project\Builds - Alert
Demo\Windows 64 bit\Alert Demo*"; DestDir: "{app}"; Flags:
ignoreversion
Source: "C:\Xojo Projects\Alert Demo\Project\Builds - Alert
Demo\Windows 64 bit\Alert Demo\Alert Demo Libs*"; DestDir:
"{app}\Alert Demo Libs"; Flags: ignoreversion
[Icons]
[Run]
[Registry]
Root: HKCR; Subkey: "AlertDemo"; Flags: uninsdeletekey
Root: HKCR; Subkey: "AlertDemo"; ValueType: "String";
ValueData: "URL:AlertDemo Protocol"; Flags: uninsdeletekey
Root: HKCR; Subkey: "AlertDemo"; ValueName: "URL Protocol";
ValueType: "String"; ValueData: ""; Flags: uninsdeletekey
Root: HKCR; Subkey: "AlertDemo\shell"; Flags: uninsdeletekey
Root: HKCR; Subkey: "AlertDemo\shell\open"; Flags:
uninsdeletekey
Root: HKCR; Subkey: "AlertDemo\shell\open\command"; Flags:
uninsdeletekey
Root: HKCR; Subkey: "AlertDemo\shell\open\command";
ValueType: String; ValueData: "{app}\Alert Demo.exe %1";
Flags: uninsdeletekey

The registry section creates the registry entries per William’s blog post.

Now that the application Is installed, we’ll look at the Web Application. For the sake of testing, I’m just adding a Button to a WebPage and adding the following code into the pressed event.

Var s As String = "Hello World"
Var Alert As String
Alert = EncodeURLComponent(s) ' Make the string URL safe
GoToURL("AlertDemo:" + Alert, True) ' Launch the app in a new tab

And that is it!

For printing a docket, I would pass a unique identifier for the transaction using this method then access the data using URLConnection & HandleURL.

Wayne Golding has been a Xojo developer since 2005 and is a Xojo MVP. He operates the IT Company Axis Direct Ltd which primarily develops applications using Xojo that integrate with Xero www.xero.com. Wayne’s hobby is robotics where he uses Xojo to build applications for his Raspberry Pi, often implementing IoT for remote control.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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:

1. Define one or more VisualStates in XAML.
2. Attach transitions to those states (for example, moving or fading an element).
3. 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.

<UserControl>
  <Grid>
    <VisualStateManager.VisualStateGroups>
      <VisualStateGroup Name="FlameStates">

        <VisualState Name="Bottom">
          <Storyboard>
            <DoubleAnimation
              Storyboard.TargetName="FlameTransform"
              Storyboard.TargetProperty="Y"
              To="40"
              Duration="0:0:1" />
          </Storyboard>
        </VisualState>

        <VisualState Name="Top">
          <Storyboard>
            <DoubleAnimation
              Storyboard.TargetName="FlameTransform"
              Storyboard.TargetProperty="Y"
              To="-100"
              Duration="0:0:1" />
          </Storyboard>
        </VisualState>

      </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>

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

      <TextBlock.RenderTransform>
        <TranslateTransform Name="FlameTransform" />
      </TextBlock.RenderTransform>

    </TextBlock>
  </Grid>
</UserControl>

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:

<UserControl>
  <Grid Width="160" Height="240">

    <!-- Fire emoji 1 -->
    <TextBlock Name="Fire1"
           Text="🔥"
           FontSize="32"
           VerticalAlignment="Bottom"
           HorizontalAlignment="Center">
      <TextBlock.RenderTransform>
        <TranslateTransform Name="Move1"/>
      </TextBlock.RenderTransform>
    </TextBlock>

    <!-- Fire emoji 2 -->
    <TextBlock Name="Fire2"
           Text="🔥"
           FontSize="26"
           VerticalAlignment="Bottom"
           HorizontalAlignment="Center"
           Margin="20,0,0,0"
           Opacity="0.8">
      <TextBlock.RenderTransform>
        <TranslateTransform Name="Move2"/>
      </TextBlock.RenderTransform>
    </TextBlock>

    <!-- Fire emoji 3 -->
    <TextBlock Name="Fire3"
           Text="🔥"
           FontSize="22"
           VerticalAlignment="Bottom"
           HorizontalAlignment="Center"
           Margin="-20,0,0,0"
           Opacity="0.7">
      <TextBlock.RenderTransform>
        <TranslateTransform Name="Move3"/>
      </TextBlock.RenderTransform>
    </TextBlock>

    <VisualStateManager.VisualStateGroups>
      <VisualStateGroup Name="FireStates">

        <VisualState Name="Off"/>

        <VisualState Name="On">
          <Storyboard RepeatBehavior="Forever">

            <!-- Fire 1 -->
            <DoubleAnimation Storyboard.TargetName="Move1"
                     Storyboard.TargetProperty="Y"
                     From="0"
                     To="-180"
                     Duration="0:0:1.2"/>

            <DoubleAnimation Storyboard.TargetName="Move1"
                     Storyboard.TargetProperty="X"
                     From="0"
                     To="10"
                     Duration="0:0:0.6"
                     AutoReverse="True"/>

            <!-- Fire 2 -->
            <DoubleAnimation Storyboard.TargetName="Move2"
                     Storyboard.TargetProperty="Y"
                     From="0"
                     To="-160"
                     Duration="0:0:1.0"
                     BeginTime="0:0:0.3"/>

            <DoubleAnimation Storyboard.TargetName="Move2"
                     Storyboard.TargetProperty="X"
                     From="0"
                     To="-12"
                     Duration="0:0:0.5"
                     AutoReverse="True"/>

            <!-- Fire 3 -->
            <DoubleAnimation Storyboard.TargetName="Move3"
                     Storyboard.TargetProperty="Y"
                     From="0"
                     To="-140"
                     Duration="0:0:1.4"
                     BeginTime="0:0:0.15"/>

            <DoubleAnimation Storyboard.TargetName="Move3"
                     Storyboard.TargetProperty="X"
                     From="0"
                     To="8"
                     Duration="0:0:0.7"
                     AutoReverse="True"/>

          </Storyboard>
        </VisualState>

      </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>

  </Grid>
</UserControl>

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

macOS 26 and iOS 26

Over time, Apple has brought the user experiences of macOS and iOS closer together. macOS 26 and iOS 26, now aligned in version numbers, also share more similarities than ever in their user experience. These updates represent the most significant user experience changes from Apple since iOS was introduced in 2007 and Aqua for macOS seven years earlier. With such a big update, especially when designing elements to work on both large computers displays as well as small smartphone screens, it’s no surprise there’s some tweaking requiring after release. Clearly, Apple is still refining its platforms.

We continue to update Xojo as Apple defines its preferred user experience, ensuring that you can deliver the best possible experience to your users.

WinUI

We are also hard at work upgrading our Windows framework to WinUI, providing a modern user experience for Windows apps. You can see our progress in each release by enabling the Use WinUI (Experimental) option on the Advanced tab in Windows build settings. The “Experimental” label is a reminder that the feature is still evolving, and it will be removed once WinUI is fully ready. Our goal has always been to keep Xojo on a steady path, prepared for whatever challenges lie ahead.

Conclusion

On behalf of the entire Xojo team, I can say that we love what we do and we appreciate your support in allowing us to do it. We are Xojo users ourselves (after all, we make Xojo with Xojo) and we enjoy seeing what you make with it. With that in mind, feel free to tell us about your creations. Send your screenshots, descriptions and your story to hello@xojo.com.

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!

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Like other controls in the Xojo framework, DesktopGrid is a data-source-based control. Instead of manually adding cells, rows, or columns as you would with a ListBox, the DesktopGrid itself requests the data it needs when it needs it. This approach brings several benefits:

ContainerControl-based cells: The cells in a DesktopGrid are full ContainerControls, just like the ones you’re already familiar with. You can use the same layout for all cells or customize different layouts for individual cells, rows, or columns. Each cell represents a live control and behaves accordingly.

• Lower memory footprint: DesktopGrid keeps only the cells that are currently visible on screen “alive,” which significantly reduces memory usage, especially when working with very large data sets. For example, when you resize the containing window, the DesktopGrid will request additional content from its DataSource only if necessary. When cells move outside the visible area of the DesktopGrid, their corresponding ContainerControl instances are “closed,” triggering an event you can handle, and freeing the memory they were using.
• Faster execution: Large data sets are not preloaded into the control. This means that opening a window with a DesktopGrid or running an app with many cells happens almost instantly, providing a smooth and responsive experience even with extensive data.

• Layout Flexibility: Since the number of rows and columns is determined by the DataSource, a DesktopGrid instance can have a flexible layout rather than a rigid, static one. For example, you can adjust the number of columns based on the available width of the DesktopGrid. You can also set different widths for individual columns, while the row height remains fixed.

• Data representation changes “on the fly”: Because the DataSource provides the content for each cell, you can dynamically change the data representation (the ContainerControl layout) at runtime or even pull data from a completely different source.
• A better separation of responsibilities: While you can implement the GridDataSource interface directly on the DesktopGrid or in its containing Window, using a dedicated DataSource class is the cleaner approach. This ensures a clearer separation between the view (the DesktopGrid), the model (the data feeding the cells), and the controller (which manages interactions between the two). A single DataSource can also feed multiple DesktopGrid instances, making your code more reusable.
• Headers everywhere: By default, DesktopGrid displays column and row headers. You can modify this in the Inspector Panel or via code. Depending on your scenario, you might choose to show both headers, just one, or hide them entirely. By default, the headers display simple numbering for each column and row. However, you can fully customize their content using the PaintHeaderContentForColumn and PaintHeaderContentForRow methods of your GridDataSource implementation, giving you complete control over how headers appear.

Is the DesktopGrid a replacement for DesktopListBox?

While you can use DesktopGrid for many purposes, it is not a direct replacement for DesktopListBox in all scenarios. If your data is primarily textual (like simple labels) or relies on features specific to DesktopListBox, such as hierarchical data representation, then DesktopListBox is still the better choice.

DesktopGrid shines in scenarios where you need complex layouts in each cell using live controls rather than temporary pictures or workarounds. Each cell can have its own layout, including interactive controls such as ListBoxes, buttons, or other reactive elements that respond to user interactions. This makes DesktopGrid ideal for rich, interactive, and highly customizable grid layouts.

Performance Caveats to Consider

Although the first iteration of DesktopGrid was designed with performance in mind, there are some factors that may affect its redraw speed. The most significant is that each cell uses live controls, so performance will be similar to placing the same number of controls directly on a Window. While alternative approaches—such as reusable cells or backing picture representations—could improve speed, they come with their own trade-offs.

As a general rule, performance depends on cell size and the number of visible cells at any given time. A large DesktopGrid with many rows and columns, even if each cell contains just a simple label, may experience slower refresh rates. Additionally, actual performance can vary depending on the operating system and its version, as these affect the underlying drawing and refresh processes.

Wiring the Grid

Although this is just the first iteration of the DesktopGrid control, we are already working on the next set of features while further refining the existing ones. You can read more about this control in the Xojo Documentation. We want to extend a big THANK YOU to everyone who provided feedback and dedicated their time testing the Grid during the beta cycle, you know who you are! Your input is invaluable, and the feature requests you submitted (combined with others already on our roadmap) will help shape a DesktopGrid that better fits your needs.

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

At this point technical assistance, feature updates and security updates is no longer provided.

Released in July 2015, Windows 10 had a good run. It was well-received and served many millions of people well. When it was introduced, Microsoft said that Windows 10 would be the “last version of Windows“, but given where we are now that clearly did not end up being true.

If your development machine is still running Windows 10, you really need to get it upgraded to Windows 11. Unfortunately, many perfectly usable computers running Windows 10 do not meet the system requirements for Windows 11, which leaves a lot of people in the lurch. If you really have to stick with Windows 10 for a while longer, Microsoft will sell you an Extended Security Update for $30. This will extend support one more year, so out to late 2026.

What does this mean for Xojo? Nothing just yet. We still have Windows 10 as a supported OS, but don’t expect that to last much longer. Once an OS vendor drops support for an OS, we have to follow that guidance at some point. Expect Xojo to discontinue Windows 10 support at some point in 2026.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Let’s build a simple but incredibly powerful Desktop app: a threaded image resizer. This tool will let you pick a folder of images and resize them all without ever locking up the app. It’s a perfect showcase of how easy and effective threading can be in Xojo.

Let’s get started!

Step 1: Designing the User Interface

First things first, let’s lay out our app’s window. We’re going for a clean and simple design. All you need to do is create a new Xojo Desktop project and add the following controls from the Library onto your main window:

1. DesktopButton: This will be our “start” button. The user will click this to select a folder and begin the resizing process. Let’s set its Caption to “Select folder && Start”.
2. DesktopProgressBar: This will give the user visual feedback on the progress of the resizing operation.
3. DesktopLabel: We’ll use this label to display status updates, like which file is currently being processed or when the job is complete. Let’s call it StatusLabel.

Your app layout should look something like this:

Step 2: Adding the Magic Ingredient: The Thread

Now for the star of the show! Go to the Library and find the Thread object. Drag and drop one onto your window. By default, it might be named Thread1, but I’ve renamed mine to ResizeThread to make its purpose crystal clear. This object is where our background work will happen.

Quick note on thread types: Cooperative threads (the default) share a single CPU core with the main/UI thread and other cooperative threads. Preemptive threads can run on separate CPU cores and deliver true parallelism for CPU-bound work. More info on this subject: Cooperative to Preemptive: Weaving New Threads into your Apps

Why this project uses Preemptive threads: resizing many images is CPU-bound and benefits from parallel cores without blocking the UI.

Step 3: Kicking Off the Process

With the UI and thread in place, let’s add the code to get things moving. Double-click the “Select folder & Start” button to add its Pressed event. This is what will run when the user clicks it.

Here’s the code for the Pressed event:

' Ask the user for a source folder (contains images)
Var f As FolderItem = FolderItem.ShowSelectFolderDialog
If f = Nil Then Return ' user cancelled

mSourceFolder = f

' Reset UI
ProgressBar1.Value = 0
StatusLabel.Text = "Starting…"

' Kick off background work!
ResizeThread.Start

Let’s break this down. First, we ask the user to select a folder. If they don’t pick one, we simply exit. If they do, we store the selected folder in a window property called mSourceFolder (Public Property mSourceFolder As FolderItem). We then reset our progress bar and status label and, most importantly, we call ResizeThread.Start. That one simple line tells our thread to wake up and get to work by running its Run event.

Step 4: The Heavy Lifting (in the Background)

The Run event of the ResizeThread is where the core logic lives. This is where we’ll find, load, resize, and save the images. Remember, the golden rule of threads is: never touch the UI directly from the Run event. Doing so can cause crashes and unpredictable behavior.

Instead, we perform our task and then send a message back to the main thread with an update. We do this using a method called AddUserInterfaceUpdate.

Here’s the Run event code:

' Quick validation up-front
If mSourceFolder = Nil Or Not mSourceFolder.Exists Or Not mSourceFolder.IsFolder Then
  Me.AddUserInterfaceUpdate(New Dictionary("progress":0, "msg":"No folder selected"))
  Return
End If

Try
  ' Ensure output subfolder "<selected>/resized" exists
  Var outFolder As FolderItem = mSourceFolder.Child("resized")
  If Not outFolder.Exists Then outFolder.CreateFolder
  
  ' Build a list of candidate image files.
  ' Note: Using Picture.Open to validate images is simple and robust.
  '       (For very large folders, you could pre-filter by extension first.)
  Var images() As FolderItem
  For Each it As FolderItem In mSourceFolder.Children
    If it = Nil Or it.IsFolder Then Continue ' Ignore subfolders
    Try
      Var p As Picture = Picture.Open(it)
      If p <> Nil Then images.Add(it)
    Catch e As RuntimeException
      ' Non-image or unreadable; skip
    End Try
  Next
  
  Var total As Integer = images.Count
  If total = 0 Then
    Me.AddUserInterfaceUpdate(New Dictionary("progress":0, "msg":"No images found"))
    Return
  End If
  
  ' Resize settings (simple “fit within 800x800” bounding box)
  Const kMaxW As Double = 800.0
  Const kMaxH As Double = 800.0
  
  ' Short delay after each file so the main thread can repaint the UI
  Const kDelayMS As Integer = 50
  
  For i As Integer = 0 To total - 1
    Var src As FolderItem = images(i)
    Try
      ' Load source (immutable)
      Var pic As Picture = Picture.Open(src)
      If pic = Nil Or pic.Width <= 0 Or pic.Height <= 0 Then Continue
      
      ' Compute proportional scale (never upscale)
      Var sW As Double = kMaxW / pic.Width
      Var sH As Double = kMaxH / pic.Height
      Var scale As Double = Min(Min(sW, sH), 1.0)
      
      Var newW As Integer = Max(1, pic.Width * scale)
      Var newH As Integer = Max(1, pic.Height * scale)
      
      ' Render into a new mutable bitmap of the target size
      Var outPic As New Picture(newW, newH)
      outPic.Graphics.DrawPicture(pic, 0, 0, newW, newH, 0, 0, pic.Width, pic.Height)
      
      ' Build a safe base name (strip the last extension; handle dotfiles)
      Var name As String = src.Name
      Var ext As String = name.LastField(".")
      Var baseName As String
      If ext = name Then
        ' No dot in the name
        baseName = name
      Else
        baseName = name.Left(name.Length - ext.Length - 1)
      End If
      If baseName.Trim = "" Then baseName = "image"
      
      ' Save JPEG (fallback PNG if JPEG export not supported)
      Var outFile As FolderItem = outFolder.Child(baseName + "_resized.jpg")
      If Picture.IsExportFormatSupported(Picture.Formats.JPEG) Then
        outPic.Save(outFile, Picture.Formats.JPEG, Picture.QualityHigh) ' adjust the quality of the jpeg here
      Else
        outPic.Save(outFolder.Child(baseName + "_resized.png"), Picture.Formats.PNG)
      End If
      
    Catch io As IOException
      ' Likely a write/permission/disk issue; skip this file
    Catch u As UnsupportedOperationException
      ' Unsupported format/operation on this platform; skip
    End Try
    
    ' Progress + message to the UI (safe handoff)
    Var pct As Integer = ((i + 1) * 100) / total
    Me.AddUserInterfaceUpdate(New Dictionary("progress":pct, _
    "msg":"Resized " + src.Name + " (" + pct.ToString + "%)"))
    
    ' Let the main thread paint the update
    Me.Sleep(kDelayMS, True) ' wakeEarly=True allows early resume when idle
  Next
  
  ' Final UI message
  Me.AddUserInterfaceUpdate(New Dictionary("progress":100, "msg":"Done"))
  
Catch e As RuntimeException
  ' Any unexpected failure: report a friendly error
  Me.AddUserInterfaceUpdate(New Dictionary("progress":0, "msg":"Error: " + e.Message))
End Try

Step 5: Receiving Updates and Safely Changing the UI

So, how does the main thread “hear” these updates? Through the UserInterfaceUpdate event on the ResizeThread itself! This event fires on the main thread, making it the one and only safe place to update our controls.

Here’s the code for the UserInterfaceUpdate event:

' This event runs on the main thread – SAFE to update controls here.
If data.Count = 0 Then Return

Var latest As Dictionary = data(data.LastIndex)

If latest.HasKey("progress") Then ProgressBar1.Value = latest.Value("progress")
If latest.HasKey("msg") Then StatusLabel.Text = latest.Value("msg")

' A little bonus: when we are done, open the output folder!
If latest.HasKey("msg") And latest.Value("msg") = "Done" Then
  Var outFolder As FolderItem = mSourceFolder.Child("resized")
  If outFolder <> Nil And outFolder.Exists Then
    outFolder.Open
  End If
End If

In this event, we receive an array of Dictionaries (all the updates that have queued up). We usually only care about the very latest one, so we grab data(data.LastIndex). Then, we safely access the values from the dictionary and assign them to ProgressBar1.Value and StatusLabel.Text. That’s it!

Conclusion

And there you have it! A fully functional, non-blocking image resizer. By moving the heavy work to a Thread, we’ve created an application that provides a smooth, professional user experience.

The pattern is simple:

1. Start the task from the main thread (ResizeThread.Start).
2. Work inside the thread’s Run event.
3. Communicate back to the UI with AddUserInterfaceUpdate.
4. Update the UI safely in the UserInterfaceUpdate event.

That’s pretty much it! Go ahead, download this project’s source code from GitHub, play around with it, and think about how you can use threads in your own applications!

Happy coding!

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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 = "<Grid>" + _
	"<CheckBox Name='CheckBox' Content='Rotate Me' IsChecked='" + isChecked.ToString + "'>" + _
	"<CheckBox.RenderTransform>" + _
	"<RotateTransform Angle='" + angle.ToString + "' CenterX='50' CenterY='10' />" + _
	"</CheckBox.RenderTransform>" + _
	"</CheckBox>" + _
	"</Grid>"

  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:

<StackPanel Orientation="Vertical">
  <Button Name="Button1" Content="Button 1"/>
  <Button Name="Button2" Content="Button 2"
           Margin="0,10,0,0"/>
  <Button Name="Button3" Content="Button 3"
           Margin="0,10,0,0"/>
</StackPanel>

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!

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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.

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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.

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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.

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!

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Xojo plugins are add-ons that extend the functionality of the Xojo development environment, allowing developers to add additional features, integrate third-party libraries, and much more.

Write a Xojo Plugin

This article assumes familiarity with the Xojo Plugin SDK and focuses on automating plugin builds. If you’re new to plugin development, check out the resources in Xojo’s “Extras” folder, YouTube tutorials, and the Xojo Forum.

It builds on my previous blog post Xojo Github Actions and involves Docker, which has also been a part of a previous blog posts (Docker, Database Servers and Xojo, Running Xojo Web Applications in Docker). So read up there on what a GitHub Actions workflow is, what the .yaml files in the Folder .github/workflows are used for.

Build a Xojo Plugin

Since Xojo is a cross platform development environment, a Xojo plugin needs to be built for all the supported platforms (Windows, macOS, Linux) and all their architectures (Intel/ARM, 32/64Bit).

All the plugin parts (the Windows .dll‘s, .macOS .dylib‘s and Linux .so‘s) are being packaged into a .xojo_plugin file.

One of the challenges is to have an environment to build all that. At the first glance it seems that one would need a Mac, a Windows machine – as well as some Linux environment (any of which could also just be a virtual machine). And one would first think that there will be a lot of manual steps involved – building the plugin source on various machines, copying all the built plugin parts together to finally assemble the resulting .xojo_plugin.

However – all that is not required. You can build a Xojo plugin without your own machine being involved, fully automated. GitHub Actions provides all we need.

Example: CubeSQLPlugin

Let us have a look at this existing Open Source Plugin.

CubeSQLPlugin is an extension for the Xojo programming environment that allows developers to use CubeSQL, a fully featured and high performance relational database management system built on top of the SQLite database engine.

The plugin is being used in the Open Sourced Administrations Tools for CubeSQL, which are both written in Xojo: CubeSQL Web Admin and CubeSQL (Desktop) Admin.

Internally the plugin uses LibreSSL for TLS Connections of Database Clients to CubeSQL Server. This means that first the LibreSSL libs need to be built for all build targets. Only then can the plugin source be built again for all build targets. And finally, all the plugin parts need to be assembled into the Xojo plugin structure for the final .xojo_plugin.

We have automated the whole build process of the plugin using GitHub Actions by having created three workflows. You’ll find their source in the folder .github/workflows. All workflow executions you’ll find on GitHub in the tab named Actions (as long as they have not been deleted or removed).

LibreSSL
This workflow will download the LibreSSL Source, and build it for all needed build targets. It needs to be run only once, e.g. if a new LibreSSL version is available that should be included for the next plugin build. That’s why it’s a workflow that can be run manually. It asks which LibreSSL version should be built and whether the built libraries should be committed and pushed to the repository.

CubeSQLPlugin
This workflow will build the CubeSQL Xojo Plugin for all build targets using the currently committed LibreSSL libs in the repository. It will commit and push all the built .dll‘s, .dylib‘s and .so‘s to the repository.

Create Release
That one is pretty obvious, right? It builds the structure of the final .xojo_plugin and creates a new Release in the repository with the final Xojo plugin – ready to be downloaded.

Build for all Platforms and Architectures

The two workflows “LibreSSL” and “CubeSQLPlugin” are similar in their approach to building for all the supported platforms (Windows, macOS, Linux) and all their architectures (Intel/ARM, 32/64Bit).

GitHub offers hosted virtual machines to run workflows. All virtual machines contain an environment of tools, packages, and settings available for GitHub Actions workflows to use.

So our workflows can simply use these environments. The workflows consist of several steps, each of which can be executed on a different runner. Remember that I’ve written: “You can build a Xojo plugin without your own machine involved”?

In the following ScreenShot we’re seeing that the Linux-ARM64 plugin part is being created on a Ubuntu 24.04.1 ARM machine.

macOS

• Runs on a GitHub macOS virtual machine.
• Uses the preinstalled Xcode command line tools to build “Intel x86_64” and “ARM64” and combine the two to a universal binary.
• CodeSigns with credentials added as repository secrets.

Linux

• ARM32, ARM64
  • Runs on a GitHub Linux virtual ARM machine.
  • To always have exactly the same build toolset (e.g. so that it doesn’t matter if GitHub updates to a newer Ubuntu version) it leverages a Docker container (e.g. arm64v8/gcc) – and actually builds the source inside the Docker container.
• i386, x86_64
  • Runs on a GitHub Linux virtual Intel machine.
  • Also uses a gcc Docker Image to build the source.

Windows

• Runs on a GitHub Windows virtual machine.
• Uses the preinstalled Visual Studio environment to build all “win32”, “x64” and “ARM64”.

How to Build your Xojo Plugin

I’m very well aware that this article can’t help you build your plugin. Each one is individual and needs its own steps and processes.

However, should you consider automating your plugin build process. You might want to look in more detail in the open-source plugin source and the workflows which are building CubeSQLPlugin for all required targets and architectures.

How to Transition from Manual to Automated

While creating a plugin, one doesn’t think of its build process in the early stages, maybe not even for the first few released versions. 

Plugin building is usually a manual process, requiring manual execution of a lot of steps and commands on various machines. It is tedious and prone to errors. It takes time, which adds up the more you build. There’s a point when one should think about streamlining and automate the process, allowing for building new versions without too much effort.
In addition, it’s certainly a good idea to have a consistent build environment other than your own development machine as you could install and change things on there which could impact the builds. That’s why building inside a Docker container is an interesting approach – it will remain exactly the same each and every time, even if the host machine is changed (e.g. by being updated to a new operating system version).

All that used to be like that before having written the GitHub workflow.

How can you transition from a manual to an automated process for your own project? I won’t be able to provide all answers. But, I’d like to give a few ideas of possible steps, with no intention of them being complete or the best choice for your project.

• Use a version control system.
  • Git and GitHub are (for many use cases) free.
  • Using a Cloud solution serves as a backup should something happen to your machines.
  • You can additionally benefit from other services such as the GitHub Actions workflows mentioned in this article.
• Everything that is only in your head should go into some written form. Once you don’t need to do something for some time, you might forget or miss something.
  • Start with documenting all steps, commands, and actions.
• Try to get rid of manual steps. Are you copy-and-pasting several commands to a terminal each and every time?
  • Put them in a shell script, so that you only need to run one command.
  • You can use these scripts later when going to a fully-automated system.
• When initial development is finished and you’re ready to release:
  • Don’t do releases from your development machine. It might be defunct, broken, stolen, or you’re installing some new cool stuff and suddenly notice issues with other projects. Having a dedicated build machine is one idea.
  • Another is going the “GitHub Actions” way which also has its benefits.
    • Runners are virtual machines that are provisioned and “fresh” every time. It’s always the very same environment to start with for each build, no matter what you’re doing during a build.
    • You don’t need to maintain many different build machines yourself. This can even solve some security issues, as it’s probably not your main interest of keeping everything up to date. I prefer to focus on programming and not on system maintenance.
    • However, the runners might be outdated in a few years – and new runners (with newer operating systems) will be available.
      • That’s usually not a very big issue on macOS and Windows since their build tools are usually backwards compatible for quite a long time.
      • Especially for Linux we have decided not to rely on the provided host but use a Docker Image and run the builds inside a Docker container. So you can, for example, use a Docker container with an image that perfectly fits your lowest compatibility needs, while the host itself might only have (too) new libraries installed.
  • Start putting all your steps and scripts into a workflow – be it just on your dedicated build environment, or using GitHub Actions.
    • Certainly separate them per required host (macOS / Windows / Linux).
    • Split a long script into smaller parts, e.g: Download LibreSSL, Build x86_64, Build arm64, Build Universal.
      • In case of an error, it’s easier to see that “macOS: Build arm64 has failed”, compared to “Build for macOS has failed” (because it’s all in a lengthy script).
• Running the workflows manually is great and likely more than good enough.
  Once the project activity grows (e.g. you’re receiving a lot of pull request or have many developers working on it):
  • Ensure that the build and test workflows are running on each pull request, require them to complete successfully before being able to merge. That by the way has been explained in the previous blog post Xojo GitHub Actions. After all, no one wants to find out after many commits that the build is no longer working, and then have to search the history for what might have caused the problem.
• You’ll notice that once it’s all automated you no longer miss it. It causes no additional effort for you, instead bringing a lot of benefits (such as noticing early when code changes cause oddities in tests and builds).

A Fun Fact

In the early days a build of the CubeSQLPlugin often took a couple of hours – and with personal attention needed so that one couldn’t work on much else during that time.

The first iteration of the workflows reduced the entire build (LibreSSL + Plugin) to about 25 minutes. With no attention and manual interaction needed – which means more time for other work. What took the longest was the LibreSSL ARM builds – they have been run on Intel hardware with QEMU for ARM emulation.

Back to the beginning of this article and Xojo’s 2025 Year of Code initiative – in February I have improved the workflows to use the newly available GitHub Actions runners that run on ARM hardware. Which means that no more emulation is required – and the build time has now come down to about 4 minutes for LibreSSL Libs (required only once per new LibreSSL version) and 2.5 minutes for the Xojo database plugin for all its supported platforms and architectures!

That’s All Folks!

I hope this brief introduction of how to use GitHub Actions workflows and Docker to build a Xojo plugin has been helpful to some, food for thought to others.

Jürg Otter is a long term user of Xojo and working for CM Informatik AG. Their Application CMI LehrerOffice is a Xojo Design Award Winner 2018. In his leisure time Jürg provides some bits and pieces for Xojo Developers.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The trick is to handle the data coming from any source with the right data structure, for example, an Array. This example uses a plain text file with several lines and columns separated by the Tab character as the source of the data.

In order to follow this tutorial, download the example project.

Getting the Data

As you can see in the example project, the text file has been added to the project using a Build > Copy Files Step (the file name is “Data.txt”), so it is copied to the Resources folder of the compiled app and available for both debugging and release builds.

Then, in the Pressed event of the Button1 control placed on the default Window1, we will access the contents of the file in order to store each of the lines in the Data Array of strings:

Var f As FolderItem = SpecialFolder.Resource("data.txt")
If f <> Nil And f.Exists Then
  Var tis As TextInputStream = TextInputStream.Open(f)
  Var s As String = tis.ReadAll
  data = s.ToArray(EndOfLine.macOS)
End If

PDFRenderer Subclass

The next step is to create a custom class that will implement the methods provided by the PDFTableDataSource Class Interface. We will name the class “PDFRenderer”. Then, from the Inspector Panel, click on the Interfaces button, check the PDFTableDataSource interface and confirm the selection.

Once done, the methods from the class interface will be automatically added to the class:

• AddNewRow
• Completed
• HeaderHeight
• MergeCellsForRow
• PaintCell
• PaintHeaderContent
• RowHeight

Over these we will add three more methods:

The class Constructor:

Public Sub Constructor(document As PDFDocument)
  // Simple constructor… just assign the received object
  // to the "Document" property
  
  Self.document = document
  proxy = New Picture(document.Graphics.Width, document.Graphics.Height)
End Sub

Assign the received PDFDocument instance to the document property. It also creates a graphics instance that will be used as a proxy for calculating the height of the processed text from the data (that won’t be necessary starting with Xojo 2024r4 where some PDFDocument bugs related with that are already fixed).

DrawTable:

This method is the one that will be called to start drawing the table. It will initialize some properties from the received Data (yeah, you can see a property named as “DrawingFromRowSet”, but I left that one on purpose because this project is based on the one dealing with the data coming from a RowSet, so you can see how similar all the process is):

Public Sub DrawTable(data() As String, headers() As String)
  // This is the method we call on the Class to draw
  // a table on a PDFDocument based on an Array of Strings
  
  If document <> Nil And data.LastIndex <> -1 Then
    
    // Assign the received Array to the "Data" property
    Self.data = data
    
    // Assign the received headers to the "Headers" property
    Self.Headers = Headers
    
    // Hey! We are going to create a table from an Array
    // so we use a Boolean property as a flag for that
    // (Yeah, we can do it using other techniques, but this
    // is easy enough for this purpose… while leave this
    // helper class "open" enough for drawing tables based on other
    // data sources).
    Self.DrawingFromRowSet = True
    
    // How many columns are we going to draw?
    // Well… as many as columns (TABs) in any of the Array items (for example, the first one).
    Var totalColumns As Integer = data(0).CountFields(Chr(9))
    
    // This is going to be the "drawable area" on the page
    // for the table = total page width less the left and right margins
    Var totalWidth As Double = document.Graphics.Width - 40 // 40 = 20 points left/right margins
    
    // Creating the PDFTable object here!
    Var table As New PDFTable
    
    // We want to repeat the headers on every page
    table.HasRepeatingHeader = True
    
    // Setting the column count for the table
    table.ColumnCount = totalColumns
    
    // …and the width for every column.
    table.ColumnWidths = CalculateColumnWidths(totalWidth, totalColumns)
    
    // The object from this class will be the responsible
    // of handling all the methods associated with the
    // PDFTableDataSouce Class Interface
    table.DataSource = Self
    
    // Setting the Top and Bottom margins for the drawing
    // of the table on every PDF page
    table.TopMargin = 20
    table.BottomMargin = 20
    
    // …and finally we instruct the PDFDocument object
    // to draw the table!
    document.AddTable(table, 20, 0)
    
    // Lastly, clearing the flag
    Self.DrawingFromRowSet = False
    
  End If
End Sub

CalculateColumnWidths Method

This one will calculate the widths for each column to be rendered in the final PDF document.

Protected Function CalculateColumnWidths(TotalWidth As Double, NumberOfColumns As Double) As String
  // Helper method to get a string for the column widths
  
  ColumnWidth = TotalWidth / NumberOfColumns
  Var s() As String
  
  For n As Integer = 0 To NumberOfColumns - 1
    s.Add(Str(ColumnWidth))
  Next
  
  Return String.FromArray(s, ",")
End Function

Class Properties

Because we need to track things like what the current row or column is to be rendered, the headers, etc., our class needs to add some properties:

• Protected Property ColumnWidth As Integer
• Public Property CurrentColumn As Integer
• Protected Property CurrentHeight As Integer
• Protected Property CurrentRow As Integer
• Protected Property data() As String
• Protected Property document As PDFDocument
• Protected Property DrawingFromRowSet As Boolean
• Public Property Headers() As String
• Protected Property LastRow As Integer
• Protected Property proxy As Picture

PDFTableDataSouce Methods

Time to visit the methods added by the PDFTableDataSouce class interface. These are the methods called by the PDFTable object each time it needs to retrieve a piece of information during the rendering on the PDFDocument, as for example if it needs to add a new row, the height for the Header or the current row… and the painting of the row itself!

AddNewRow Method

This one is called by the PDFTable object in order to know if it needs to render a new row in the table:

Protected Function AddNewRow(rowCount As Integer) As Boolean
  // Part of the PDFTableDataSource interface.
  
  If DrawingFromRowSet And data.LastIndex <> -1 then
    
    // We are going to draw as many rows as rows are in the
    // "data" array
    Return rowCount <= data.LastIndex
    
  End If
End Function

Completed method

This is the method invoked by the PDFTable object when it finished drawing the table, so it is your chance to take additional operations, for example, numbering every page of the PDFDocument (we can’t anticipate that before drawing the table itself):

Protected Sub Completed(x As Double, y As Double)
  // Part of the PDFTableDataSource interface.
  
  // This method is called once the table has been drawed
  // so let's "print" the page number on every page
  // of the PDF Document
  
  Static pageNumber As String = "Page: "
  
  If document <> Nil Then
    Var g As Graphics = document.Graphics
    
    For n As Integer = 1 To document.PageCount
      document.CurrentPage = n
      g.DrawText(pageNumber + Str(n), g.Width - g.TextWidth(pageNumber + Str(n)) - 20, g.Height - g.FontAscent)
    Next
    
  End If
End Sub

HeaderHeight Method

This is the method called by the PDFTable object the returns the height we want to use for rendering the header on the first page and, optionally, on every new page required (added to the document) by rendering the table. In this case we will return a fixed value:

Protected Function HeaderHeight() As Double
  // Part of the PDFTableDataSource interface.
  
  // Returning a fixed height value for the headers
  Return 20
End Function

MergeCellsForRow Method

The PDFTableDataSouce class interface also has the ability to merge cells in the current row, so you can create more elaborated tables. We are not going to use that feature in this example project so it will be empty, no code to be executed.

PaintHeaderContent Method

This is the method in charge of rendering the header for the table, so it receives its own Graphic context with the provided height from the HeaderHeight method and the width calculated from the total of columns (headers) needed to be rendered:

Protected Sub PaintHeaderContent(g As Graphics, column As Integer)
  // Part of the PDFTableDataSource interface.
  
  // Painting the headers for the table
  If column <= Self.Headers.LastIndex Then
    
    Var s As String = headers(column)
    g.DrawingColor = Color.Black
    g.FillRectangle(0, 0, g.Width, g.Height)
    g.DrawingColor = Color.White
    g.DrawText(s, g.Width / 2 - g.TextWidth(headers(column)) / 2, g.Height / 2 + g.FontAscent / 2)
    
  End If
End Sub

RowHeight Method

As the class interface provides a method so we can provide the height for the header, we also have a RowHeight method that the PDFTable object will call before it calls the method in charge of doing the row drawing itself. That way we can have rows of different height based on the height of the own text to be rendered!

Protected Function RowHeight() As Double
  // Part of the PDFTableDataSource interface.
  
  // We need to calculate the height for every row in the Table
  // so let's calculate that based on the taller of the texts (columns)
  // based on text wrapping
  
  If CurrentRow <= data.LastIndex Then
    CurrentHeight = 0
    Var s() As String = data(CurrentRow).Split(Chr(9))
    Var g As Graphics = proxy.Graphics
    Var itemHeight As Integer
    For Each item As String In s
      itemHeight = g.TextHeight(item, ColumnWidth - 40)
      If itemHeight > CurrentHeight Then
        CurrentHeight = itemHeight
      End If
    Next
    
    CurrentRow = CurrentRow  + 1 
    
    Return CurrentHeight + 20
  End If
End Function

PaintCell Method

Lastly, this is the method called by the PDFTable object when it is time to render a given cell for the current row in the table. It receives as parameters both a graphic context with the width and height already suited for the data to be rendered, and also the row and column values so you can get the appropriate data for a given cell from the data source:

Protected Sub PaintCell(g As Graphics, row As Integer, column As Integer)
  // Part of the PDFTableDataSource interface.
  
  // Here is where we really do the drawing
  // the received "g" parameter is for a particula table cell
  // based on the row / column parameters
  // so the origin for X/Y coordinates is at 0,0
  
  If DrawingFromRowSet And data.LastIndex >= row Then
    // Drawing the outer rectangle for the cell
    g.DrawRectangle(0, 0, g.Width, g.Height)
    
    // retrieving the text to be drawn from the Array,
    // using the row and column parameters for that.
    Var s As String = data(row).NthField(Chr(9), column + 1)
    
    // Centering vertically the text on the table cell
    // while the X offset is fixed at 5 points.
    g.DrawText(s, 5, g.Height / 2 + g.FontAscent / 2, ColumnWidth - 20)
    
    // Let's keep track of the last row drawed
    LastRow = row
    
  End If
End Sub

Time to push the Start button!

Everything is setup now in our PDFRenderer class, so let’s get back to the Pressed event of the Button1 control on the default Window1 window. You will remember from the beginning of this tutorial that this is the place where we retrieved the data from the text file. So let’s add the code to create a PDFDocument instance, a new PDFRenderer instance and do the rendering of the table itself from the data:

If data.LastIndex <> -1 Then
  
  // Creating a new PDFDocument Instance
  Var d As New PDFDocument
  
  // Creating the PDFTable renderer helper object (we pass the PDFDocument object to it in the Constructor)
  Var PDFRender As New PDFRenderer(d)
  
  // These will be the headers drawed in the Table
  Var headers() As String = Array("Name", "Surname", "Address", "City", "Email")
  
  // And let's instruct the PDFTable renderer helper to draw the table
  // based in the SQLite database rowset we got in the previous step
  PDFRender.DrawTable(data, headers)
  
  // …and save the resulting PDF File to the Desktop
  Var out As FolderItem = SpecialFolder.Desktop.Child("TableFromTextFile.pdf")
  
  If out <> Nil Then
    d.Save(out)
    out.Open
  End If
End If

Conclusion

As you see, and if this tutorial is compared with PDFTable from a RowSet, creating a PDFTable doesn’t differ too much when using a data source other than a RowSet. All you need, basically, is to keep track of the current row, know if you need to render more rows and a base data structure that can be used to retrieve the data to be rendered in a given Row/Column.

As always, you can learn more about other features provided by PDFDocument in the Xojo Documentation.

Happy Coding!

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

EKlectic Accounting is a new, full-featured, professional accounting application made with Xojo by independent developer Edward Kidwell. EKlectic’s user interface is “QuickBooks-like” and will feel familiar to users of other accounting software. All the code for EKlectic Accounting is “pure Xojo”, and uses no plugins. The application is cross-platform and supported on macOS and Windows.

10 Questions with Edward Kidwell

You mentioned your projects are “pure Xojo” and don’t use any plugins. Can you tell us about that?

I was originally drawn to Xojo by an open-source project that turned out to be heavily dependent on third-party plugins. Even after I had purchased a Xojo Pro license, I couldn’t compile the project without additional purchases. Furthermore, as I dug deeper, I found the functionality provided by the plugins was easier to write in Xojo than it was to implement the plugin. I decided at that point that I would strive for all of my projects to be cross-platform compilable without any third-party purchases being necessary. Several projects later, I have not had to compromise that decision.

Although Xojo is a RAD environment (Rapid Access Development), I’ve observed (on the Xojo forum) that many developers overlook the power that is available in the core language and built-in objects. Anyone using the forum will notice that many answers basically say, “Use plugin ABC for that,” when Xojo itself could often solve the problem without any plugins. For developers who are packaging and reselling their software, I think the less third-party dependencies the package has, the easier it is to maintain, support, and debug.

For example, without using any third-party software, I’ve created reusable Xojo objects for PDF (with both print and preview), ID3 audio-tags-reader (for MP3 files), and custom controls (database-enabled auto-completing dropdown fields, GUI panels, etc). Xojo really can stand “on its own two feet”!

Mac, Windows or Linux?

All of the above! My primary machine is Mac, with a separate Windows machine on a different HDMI channel, and I use various Linux VMs as needed.

What do you wish more people would ask/talk to you about when it comes to the software you develop? 

I wish more people offered criticism of the user experience. Only through critical feedback can you improve a software package, and I’ve learned to appreciate it when people complain.

What’s next on your “Learn Next” list?

In the context of computers, the Rust language has piqued my interest. Besides that, I’m currently studying Greek.

When do you think of solutions for stubborn bugs?

*Always* first thing in the morning. The mind seems to solve them overnight.

What programming moments made you think “Wow, I love my job so much.”

I felt that way when, using Xojo’s ServerSocket and TCPSocket classes, I was able to implement a bonafide HTTP 1.1 server written from scratch in Xojo. I packaged that code as a reusable object that I can plop in to any of my projects. For example, one of my projects uses that server to allow users to control the app remotely from any device on the same network (e.g. iPhone, iPad, Android, and even Kindle tablets). So yeah … it is very satisfying to see my Xojo apps serving up their own HTML and JavaScript web apps, as well!

What is something that has surprised you about coding in the last 10 years?

Two things: 1) How fast certain new languages are adopted (e.g. Swift, Rust), and 2) How indispensable some of the older languages have become (e.g. C++, PHP … they’ll never die! ).

What’s the coolest thing you worked on recently?

There are actually two very “geeky” things that come to mind: The first is a shell script I created on TrueNAS (FreeBSD) using rsync to *pull* scheduled (cron) backups of a remote Linux web server over an authenticated SSH connection. The core functions from the script are also used on my Mac to *push* scheduled backups to the TrueNAS. That made my “geek sense tingle” a bit. Secondly, I created a web-based VOIP phone system (like the automated attendants in a PBX) using a RESTful API on the backend, and a home-grown web-app-GUI on the frontend. It allows people to setup a complete phone system in one or more languages and with different voices, all through a web interface. Again, “geek-sense=tingly.”

Music or no music while coding?

I’m a multi-instrument musician of over 4 decades, so yes, always!

In addition to accounting software, Ed offers additional apps built in Xojo. EKlecticSong is a presentation program for song services, church services, or business presentations. EKlectic Find Duplicates is a duplicate finder with a fast duplicate algorithm. Dock Media is a full-featured yet minimalistic media player.

Thank you to Ed Kidwell for answering our questions and sharing his experience with Xojo with us. If you have an app, a project or a person you want to see featured in Spotlight On, tell us about it!

Some of you might not have noticed because, until recently, most people didn’t think much about Windows ARM. After all, nearly everyone still runs Windows on x86-64 CPUs. But lately, Windows on ARM is starting to get more traction, both in the press and in the market.

Back in May, Qualcomm announced the Snapdragon Dev Kit for Windows. This is supposed to be a $900 mini PC (about the size of a Mac mini) for developing Windows ARM apps for the Snapdragon X Elite SoC (system on a chip). I say “supposed to be” because although the press release says it was intended to go on sale on June 18, I can only find pre-order pages for it, so it seems to not be available just yet or out-of-stock.

There have been other ARM PCs for Windows in the past, but their performance has always been less than desirable. The new Snapdragon X Elite is supposed to be roughly equivalent to Apple M3 SoCs.

You don’t have to wait for Qualcomm as Copilot+ PCs and laptops with Snapdragon SoCs are starting to appear elsewhere. Lenovo has the ThinkPad T14s Gen 6, which at about $1700 is not exactly a bargain, but is in the ballpark of many Mac laptops. The Yoga Slim 7x is even cheaper starting at just $1200.

But I’m not here to sell Lenovo products. I’m just pointing out that Windows on ARM is becoming a reality, if slowly. That might be starting to change given Intel’s recent troubles with its Raptor Lake CPUs and most recent earnings report, however. Take it with a grain of salt, but Qualcomm is predicting that Windows ARM could reach 50% of Windows PC market within five years.

That sounds astonishing, but change often happens slowly then all at once.

Building for Windows ARM with Xojo

The good news is that with Xojo you are already prepared for this. To build your existing Xojo desktop project for Windows ARM, you just need to change one property in the Windows Build Settings and click Build. There is no step 3.

Xojo can also build Windows apps for x86-64 and x86-32, which pretty much covers all your bases. Not to mention that it can build macOS apps, Linux apps, web apps, iOS apps and Android apps.

And if you already have an Apple Silicon Mac then you don’t even need to purchase a Windows ARM computer. You can run Windows ARM as a virtual machine on a Mac using Parallels or VMware Fusion. You’ll still need to get your own license for Windows 11, however.

Although you can make your own Windows ARM apps with Xojo today, there are a couple temporary limitations to keep in mind. The first one is that XojoScript is not yet available. The other is that Xojo itself is not yet a native Windows ARM app. Both of these are because the Xojo compiler itself is not yet native on Windows ARM. That will change, but for now Xojo itself runs perfectly fine using the Prism x86-64 emulation layer in Windows. In addition you can use the Remote Debugger to test your apps on Windows ARM from another computer.

Will Windows ARM replace Intel like it did for Macs? It seems hard to believe, but the wind seems to be blowing in that direction. To make sure you’re prepared, download Xojo for free today and start creating your own ARM apps!

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

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.

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

And what do we mean by the transitory character of Popover windows? Well, and here comes one of the first differences from Modal windows. When a Popover is visible and the user clicks or taps on any other element of the graphical interface not contained in the Popover itself it will close, hence transitory. So, you don’t have to include the typical “Close window” button in a Popover (though you can), since it will close when the user clicks outside of it, i.e. when the Popover loses focus.

Where are the Popover Window Contents?

Where do you define the content displayed in a Popover window? While in your Web app, you can do it on any Container control added to the project. In the case of Desktop and iOS apps, you can do it on either the designs of a Container Control or any Window or Screen added to the project.

For example, here you can see that the content shown as a Popover in the previous screenshot is actually that of a Window (Window2) added to the project:

This introduces additional flexibility allowing your app’s logic to decide when to display a Window or Container instance as you have been doing until now, or display it as a Popover.

Showing a Popover

Displaying a Popover is very straightforward, whether it is created from a Container or a Window, the method is the same:

DesktopContainer.ShowPopover(parentControl As DesktopUIControl, facing As DesktopWindow.DisplaySides = DesktopWindow.DisplaySides.Bottom, detachable As Boolean = True)

The explanation of the expected parameters is as follows:

• ParentControl: The control that will act as the parent, or on which the Popover will be pointing to.
• Facing: The direction in which the Popover will point on the parent control; by default it will appear under the parent control, but you can use any of the values available in the DesktopWindow.DisplaySides enumerator (or the iOS equivalent).
• Detachable: This value only applies to macOS Popovers, since said operating system has the ability for the user to “detach” the Popover from the parent control as long as this value is defined as True. To detach, drag the Popover with the mouse cursor.

Let’s say we have a window called Window2 and a button called MyButton. In the Pressed event of MyButton we can use the following lines of code to display Window2 as a Popover:

Var w As New Window2
w.ShowPopover(me)

And that’s all!

Platform Differences

In the previous section we already pointed out the first: macOS is the only operating system that acts on the value indicated in the Detachable parameter. But there are some other considerations to keep in mind so you don’t get caught off guard:

• Beyond the limits. Although in Windows and macOS Popovers can exceed the limits of the window on which the parent control is located, the position of the popover in Linux is restricted to the limits of the window that contains the parent control. This is the same for iOS and for Web pages.
• iPhone and iPad. When a Popover is displayed on an iPhone, it will look like a modal window; while if the same application is run on an iPad, the appearance will be the typical one expected from Popovers: the window pointing to the parent control in the indicated direction.
• On the Web. The contents of a Popover are those defined in a Container control, while on the rest of the platforms you can use both Container controls and Windows / Screens.

Why the Popover doesn’t “point” in the configured direction?

By default it will try to do so according to the value that has been set in the “facing” parameter, but if it does not find enough space on the margins of the screen, then it will be displayed on the next side of the parent control in which there is available space for display the Popover in its full width and height; This is true on macOS, Linux, Web and iOS.

Can I reuse a Popover?

No, You can not. Whether you use a Container control or a window as the source of the UI design to be displayed by the Popover, do not lose sight of the fact that the Popover is just another type of window; and therefore behaves as such. That is, once it is closed either because it has lost focus or because you have closed it explicitly through code invoking the Close method, all the displayed controls and the rest of the internal structures will be closed / invalidated, so that although the instance If a Popover is not Nil (because, for example, you keep a reference to the window or container instance used as the UI source), you will not be able to invoke the ShowPopover method again on said instance but you will have to create a new instance of the Container/ Window used as the source of the UI to be displayed by the Popover.

How can I communicate with the UI elements contained in the Popover?

You would do so just as you would do with any other type of window that you have been using so far in your Xojo projects.

Conclusion

Without a doubt, Popovers are a new way to improve the design of your apps’ user interfaces, providing a more direct relationship between the user interface elements displayed in the Popover and the “parent” control in charge of displaying it. Furthermore, since you can use any window or container you want as the source of the UI to be displayed by the Popover, you will have greater flexibility about when you want to display them in a Popover or display them using any other of the available window types or, in the case of Containers, embedding them as part of other UI elements at runtime.

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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.

<winui:TabView>
	<winui:TabView.TabItems>
		<winui:TabViewItem Header="Tab 1">
			<StackPanel>
				<TextBlock Text="This is Tab 1" Margin="5"/>
				<Button Content="Button 1" Margin="5"/>
				<CheckBox Content="Checkbox 1" IsChecked="True" Margin="5"/>
			</StackPanel>
		</winui:TabViewItem>
		<winui:TabViewItem Header="Tab 2">
			<StackPanel>
				<TextBlock Text="This is Tab 2" Margin="5"/>
				<TextBox Text="Enter text here" Margin="5"/>
				<ComboBox Margin="5">
					<ComboBoxItem Content="Item 1"/>
					<ComboBoxItem Content="Item 2"/>
					<ComboBoxItem Content="Item 3"/>
				</ComboBox>
			</StackPanel>
		</winui:TabViewItem>
	</winui:TabView.TabItems>
</winui:TabView>

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.

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Generate Codes

The ability to generate codes and identify them from images is available as a shared method for the indicated platforms, in desktop and console apps. The latter is interesting because it means that you can use this functionality in web apps deployed on Windows or Mac servers.

Creating QR or Bar128 codes couldn’t be simpler. Since it uses a shared method, it is not even necessary to have previously created an instance of the class, you only need to invoke the method:

Barcode.Image(value As String, width As Integer, height As Integer, type As Barcode.Types = Barcode.Types.QR) As Picture

Where the expected parameters are the following:

• Value: Source text string that will be converted to the indicated code type
• Width: Width of the resulting image with the generated code
• Height: Height of the resulting image with the generated code
• Type: The type of code you want to generate. It can be QR or Bar128; these values are available in the Barcode.Types enumerator

Once the method is invoked, you will obtain an image (Picture) that you can use in your app; or you will receive an InvalidArgumentException if some of the parameters provided are invalid, such as passing an empty text string as the data source.

For example, the following line of code generates a 120 x 120 image corresponding to a QR code with the text provided:

Var p As Picture = Barcode.Image("Xojo Rocks!", 120, 120, Barcode.Types.QR)

Recognize Codes in Images

In the same way it is possible to generate code images from text, it is also possible to recognize up to twelve different types of codes from an image. To do this we will use another shared method of the Barcode class:

Barcode.FromImage(image As Picture) As String()

As you can see, in this case the method will return an array of Strings with the values of the recognized codes. It is possible that the image contains more than one code; but it is also possible that no code could be recognized in the provided image, so it is advisable to check the limits of the received array before proceeding.

For example, this line of code will recognize the codes available in the MyPicture image and return the values in the RecognizedCodes() array:

Var RecognizedCodes() As String = Barcode.FromImage(MyPicture)

Scan Codes

Scanning QR codes (or any of the other supported codes) on desktop is only available for macOS and Windows platforms. This is due to desktop presenting a user interface where you can preview the image captured by the selected camera. You can select the camera to use to scan from those connected to the computer (including, for example, iOS devices in the case of Mac, through Continuity; or Android devices paired with your Windows computer). In the case of Mac, the ability to scan images is only available using macOS 10.15 or higher.

To scan codes directly using any of the cameras connected to the computer it is necessary to have previously created an instance of the Barcode class (for example, drag the class from the IDE Library onto the tray area in the Layout Editor window):

Doing so will add it to the Project Browser where we can select it and implement any of the three available Event Handlers:

• ScanCancelled: The user has canceled the code scanning operation, such as by closing the presented UI window
• ScanCompleted: Receive the value as String corresponding to the code detected by the camera
• ScanFailed: Raised when some type of error has occurred, such as the fact that no camera is detected

To display the code scanning UI, invoke the StartScan method on the created Barcode instance. For example:

Barcode1.StartScan

The scan UI does not close automatically when a code is recognized to allow scanning a series of codes (such as in the case of inventory), so it is also possible to stop the operation by code by calling the StopScan method. For example, you can include this line of code in the ScanCompleted event of the Barcode1 instance after the received value has been processed:

me.StopScan

As expected, invoking the StopScan method from code will close the code scanning UI.

Conclusion

Now you can create all types of applications on macOS, Windows and iOS with the ability to generate and scan QR codes, Barcodes and other types of codes, opening up a wide field of possibilities for Xojo users.

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Faster HandleURL Responses

With Xojo Web you can create APIs backing your Mobile or Desktop applications. Just by updating to Xojo 2023r4, your web services will get the benefit of much faster responses and the ability to handle many more requests per second.

Just to compare between different Xojo versions, we’ve created some benchmarks using Xojo Web 1 (with Xojo 2019r3.2) and some Xojo Web 2 releases, 2023r3.1 and the latest one, 2023r4.

Here are the results, returning plain text:

And the same test, but this time returning a string generated by JSONItem:

Xojo 2023r4 is capable of serving around 20x more requests per second compared to Web 1, and around 4x compared to Xojo 2023r3.1. And thanks to the reduced latency time, your API will return the contents much faster.

Faster Transfer Rates in Windows and Linux

While working on performance, we’ve found that applications deployed on Windows and Linux were serving large files much slower than those deployed on macOS servers.

William improved the low level code for sockets on those targets, allowing the server to transfer large files at a much faster speed. During my tests, I’ve seen 10x faster transfer rates.

But this doesn’t affect only our Web target! If you are using a ServerSocket with TCPSocket classes, your Console and Desktop applications will also benefit from these improved transfer rates.

Static Assets Cache Control

In this release, we’ve also improved how the framework interacts with the browser. When your user visits your web application for the first time, it will store all of the required JavaScript and CSS files.

This was already happening in previous releases but with a subtle difference. From now on, the browser won’t even need to check with the server if the file has changed since the last visit. This translates to faster load times for your users and less server load for you since the server won’t need to handle all those requests anymore.

Improved Compile Time

In this release, Xojo Web will compile your projects a few seconds faster. The first time you compile your project, it will cache the result of some processes that are only changing between Xojo releases.

Here is a comparison between 2023r3.1 and 2023r4, both are running a debug session of a blank project:

That’s around 3-4 seconds faster every time a project compiles.

Events Improvements

Some web controls were sending information from the browser to the server more frequently than needed. For example, a WebContainer.Scrolled event was being sent for every scrolled pixel, causing unnecessary server load.

We’ve been reviewing these controls and have made some improvements:

• WebCombobox
• WebContainer
• WebSearchField
• WebTextArea
• WebTextField
• WebUploader

All of them will continue communicating their state updates, but the framework will focus on delivering the latest value available.

For example, in a WebSearchField, if the user writes “hello”, the framework will send the first key press (“h”) as soon as it happens. The next event it will send will depend on how fast the user types, so it can be either “hel” or maybe directly “hello”. What is guaranteed is the TextChanged event will be fired for the final value (“hello” in this example).

New Experimental Option

WebSession has a new experimental option available, disabled by default. “Send Events in Batches”:

Turning it on will make our JavaScript framework group different event notifications in a single request. Projects that contain complex layouts that show and hide several controls at once may benefit from snappier GUIs.

As a side effect, it will also ensure the events arrive to the server in the correct order. Think about a login screen where the user has an email field, a password and a “Login” button with the Default setting turned on (to allow the user to trigger the Pressed event by pressing the Enter key). When sending the events in different requests, because of network latencies, the WebButton.Pressed event could arrive at the server before the last WebTextField.TextChanged.

We would love to hear your experiences when turning on this experimental option. If you find an issue, please report it.

Wrapping Up

As always, while Xojo 2023r4 comes with a lot of performance improvements, it also comes with bug fixes and feature requests. I want to again thank everyone who took the time to create new Bug reports and Feature Requests, and tested the pre-releases.

We’re looking forward to see what you build with it!

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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.

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

You still hear this same argument today in the software development world, where the big names are Microsoft, Apple and Google.

But how “safe” is their stuff, really? After all, they all seem to end support for products and tools rather often.

Microsoft recently announced that they are discontinuing Visual Studio for Mac, which was only just introduced in 2016. Last I checked, Microsoft is a Very. Big. Company. Yet they somehow cannot justify resources to keep a Mac IDE viable. Clearly, they have the resources so this is a decision about Microsoft’s focus and priorities, things that Big Companies change all the time.

Google drops products (or drastically changes them) often. Changing their “free for life” Google Apps (G Suite) product to a rather expensive monthly cost was not popular with many businesses.

Apple killed off iBooks Author, and although it was not a development tool, it was something that was heavily promoted for a while as the best way to make content for the iBooks Store. In the development world, Apple killed off their Carbon OS framework in favor of Cocoa after years of telling developers the two would co-exist.

In the 2000s before working here at Xojo, I did a lot of consulting (frequently migrating VB6 apps to Xojo) and one question that was often asked of me is “why should I go with a dev tool from a small company like Xojo instead of something from a big name like Microsoft?”.

The answer I always gave at the time was: “You’re coming to me to migrate a VB6 app. VB6 was from Microsoft and they killed the product off. Big companies do that all the time. A small company like Xojo focuses entirely on their product. It gets all their attention. If you had picked Xojo in 1999 instead of VB6, we would not be having this conversation right now.”

To that end, Xojo has been around since 1998 and has outlived many other development tools and platforms. Some of which come to mind are: Visual Basic 6, Metrowerks CodeWarrior, and (now) Microsoft Visual Studio for Mac.

Technologies are also regularly discontinued by the creators in favor of newer versions. It took years for the Python community to move from Python 2 to Python 3. But when Apple finally removed Python 2 from macOS last year, there were many apps and companies that had to scramble to update their code. PHP8 was release in 2020, but as of today adoption is only about 12%. In 2017, Google switched from Java to Kotlin as the official language of Android, impacting many. Apple promotes Swift and Swift UI over Objective-C and AppKit these days. They introduced Catalyst, but it appears to not be making much headway. Microsoft pushes out new frameworks at a rapid pace, which is exciting, but can be difficult for a development team to know what to pick.

I don’t bring these things up to point out mistakes. Change is inevitable in technology after all. I only bring these up to point out that, even with the big names, there are still risks.

All this is to say that if you are an enterprise company with a large investment in software and IT, you might want to take a look outside the big names and see what Xojo can offer. I realize that if you have standardized on a set of tools from a large vendor, say C# and Microsoft, you are probably thinking “there’s no way I’m switching to Xojo no matter what this guy says”.

We at Xojo agree. You probably should not be switching everything over to Xojo. That would be insanely expensive and risky. But Xojo can be a great complement to the tools you already use. Professional software developers (and their companies) keep lots of tools in their toolbox and Xojo should be one of those tools.

So what can Xojo do for you?

Xojo’s goal is to make programming easier, allowing you to get software made faster. Xojo saves you time and money. To that end, in enterprise environments Xojo is great for:

• Prototypes and proof-of-concepts
• Internal tools and utilities
• Testing
• Demos

With Xojo you can quickly build a desktop app (for mac, Windows or Linux) to test out REST APIs. You can build a web app to demonstrate some UI concepts or easily distribute information. You can build a mobile app (iOS or Android) to quickly try out ideas. Xojo lets you do All The Things without having to deal with a bunch of different complex tools and technologies. Xojo can give you the speed and power of low-code tools without all the limitations.

Xojo makes it quicker and easier to try out software ideas before you commit expensive development resources to your primary tools. A company’s biggest expense is usually salary and using an expensive IT department to slowly build everything is not a great value. You spend too much money on salary and sacrifice too much time on lost opportunities. Using Xojo instead can save you significant money that you can put towards the projects you determine are viable and worth more investment.

And don’t forget about internal tools. Every company needs internal tools of some kind and these won’t generate revenue on their own. Forcing these tools to go through an overworked IT department is slow and expensive. But not building them at all means your staff is less productive than they could be. Your advanced power users can use Xojo to create tools that will improve productivity at a fraction of the cost and avoid lost opportunities waiting for IT.

Like Apple, Google and Microsoft, Xojo isn’t perfect. We’ve made our share of mistakes, such as our transition from Web 1.0 to Web 2.0 which was not as smooth as we had hoped it would be. The team is only human, but we do our best to learn from mistakes and if nothing else we are perseverant and committed to always making Xojo better. The fact that we’ve been doing this since 1998 is a testament to that.

So join the many other enterprise customers that use Xojo as a secret weapon! You might find you like using a development tool from a small company that cares about its product and its customers.

You can try Xojo for free today. Licensing is available for as low as $399 per user (even lower when purchased in bulk). Contact us at hello@xojo.com for more information or to get a quote.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

1. Drag a DesktopXAMLContainer to a window.
2. Add the Opening event handler.
3. 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 = "<Button Name='Button' Content='" + Hello + "' />"

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.

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:

<Button Content="Hello World" />

Note: XAML is case sensitive so <button Content="Hello World" /> would be an error because “button” needs to be capitalized to “Button”

Great but where do I put this XAML code?

The XAML code can be added to the DesktopXAMLContainer’s Content property. First, find and add the DesktopXAMLContainer control to your layout.

Next, add the XAML code to the Content property, the Layout Editor should now update with a visual of a WinUI Button.

Are there other XAML controls I can add?

Yes, we provide a convenient list of XAML controls that can be added to your layout if you open up the XAML Control Chooser dialog, by bringing up the contextual menu for that control.

This list includes 30+ controls that are ready to be added to your layout with helpful documentation on the side.

Neat, so how do you handle events?

All XAML related events are filtered to the DesktopXAMLContainer.EventTriggered event. In this event you have the opportunity to check the name of the event that triggered it. For our Button example, we note that it fires a “Click” event.

To see more of you can do with XAML, make sure to check out Xojo’s Example Projects included in the Examples folder of the Xojo Download, the Xojo Documentation and Doing More With DesktopXAMLContainer.

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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.

<StackPanel Orientation="Vertical">
  <Button Content="Button 1"/>
  <Button Content="Button 2"
           Margin="0,10,0,0"/>
  <Button Content="Button 3"
           Margin="0,10,0,0"/>
</StackPanel>

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

<StackPanel Orientation="Horizontal">
  <Button Content="Button 1"/>
  <Button Content="Button 2"
           Margin="10,0,0,0"/>
  <Button Content="Button 3"
           Margin="10,0,0,0"/>
</StackPanel>

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.

<StackPanel Orientation="Vertical">
  <Button Name="Button1" Content="Button 1"/>
  <Button Name="Button2" Content="Button 2"
           Margin="0,10,0,0"/>
  <Button Name="Button3" Content="Button 3"
           Margin="0,10,0,0"/>
</StackPanel>

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 = "<Button Content='My new caption'/>"

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") = "<ProgressRing />"

This would be the equivalent XAML code:

<Button>
  <ProgressRing />
</Button>

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.

<winui:ProgressRing />

<ProgressRing />

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.

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube