Desktop – Xojo Programming Blog

Code Signing on macOS: What Developers Need to Know, Part 4

Javier Menendez — Tue, 07 Apr 2026 19:00:00 +0000

In the previous article, we saw how signing a macOS app is more than just handling certificates. Other factors come into play based on the distribution method you choose and the features it will offer.

Now, that we already know all the pieces involved in this particular puzzle (certificates, sandboxing, notarization, hardened runtime, etc.), the question to answer is…

What kind of macOS code signing do you want to do today?

Apple developer certificates installed on your Mac determine the kind of code signing and, thus, the distribution options available for your macOS app. They can also support certain macOS security requirements that distribution methods or features may impose, such as entitlements or provisioning profiles.

This diagram can help determine these based on the certificate used when signing the app, so you can get a better idea:

As a practical summary:

Ad-Hoc signing / None: This option makes sense primarily when you’re developing and running or debugging the app on your Mac or on the same computer, since it typically doesn’t require special entitlements or provisioning profiles.
Apple Developer / Development. Using this certificate enables sandboxing, hardened runtime, entitlements and provisioning profiles even when debugging from the IDE or testing the build on your own computer. It offers a better experience, but you won’t be able to notarize it or bypass the Gatekeeper barrier if distributed to other users.
Developer ID Application / Direct Distribution. With this certificate, you can notarize your app so Gatekeeper won’t block distribution outside the Mac App Store. When debugging from the IDE, entitlements and provisioning profiles (if needed) are applied as well, along with optional sandboxing.
Apple Distribution / App Store. Use this certificate when the app has been tested and it is ready to be sent to App Store Connect… or even when you’re planning to send it to the App Store Connect so a group of beta-testers can test it using Apple’s TestFlight.

How the Xojo IDE helps with all of this?

We have been adding features to the Xojo IDE to make code signing and distributing your macOS apps an easier and leaner process; most of these are available under Build Settings > macOS > Sign:

Developer ID – Build For

This is the most recent addition to better deal with the first, and most important, piece of the puzzle: handling certificates! Instead of having to go back and forth between the Keychain Access and the Xojo IDE to copy/paste the expected data from the certificates for the kind of build or distribution you plan for the app, you can now find under the Developer ID field all the available Developer Teams (usually just yours) and, when a Developer Team is selected, the “Build For” popup menu will be populated with the available options for builds/distributions based on the installed developer certificates for that team.

When all the Apple developer certificates are properly installed for a given Developer Team, the available options will be: Development, Direct Distribution and App Store (plus None, meaning Ad-Hoc signing).

If you find that some of these options are missing from the “Build For” popup menu, that means the corresponding certificate is not installed or there is some kind of issue with that certificate (maybe it has expired or has its private key missing). In those cases, we included the “Inspect…” option under the “Developer ID” popup menu. Selecting Inspect lets you gain a better picture about everything related to your Apple developer certificates and even get advice about how to fix the most common issues.

Sandboxing

Enable this feature if you plan to debug, build, or distribute your app as a sandboxed app. In that case, the associated editor will make it even easier to enable the sandboxing features that may apply to your particular app. The IDE will take care of all the rest. Note that, while sandboxing was previously only applied to built/distributed macOS apps in previous Xojo releases, starting with Xojo 2026r1 it is also applied when the app is being debugged from the IDE.

Hardened Runtime

Enable this option mainly for apps meant to be built and/or distributed using Direct Distribution or the App Store options. While this is optional when distributing it via the Mac App Store, it is still highly recommended to enable it for that scenario.

When the app is debugged from the IDE, the hardened runtime won’t be applied even if it is enabled… mainly so you can debug it!

As with sandboxing, the hardened runtime option also includes its own editor to make your app-specific selections easier. The IDE will take care of the under the hood processing when the app is built.

Notarization

If you haven’t started notarizing your macOS apps yet, now is the time! This will be possible only with the Direct Distribution option (equivalent to the Developer ID Application Certificate) and implies enabling hardened runtime. When you enable notarization, the associated hardened runtime will be enabled for you, even if you don’t select additional option from its editor.

Notarization requires the use of what Apple calls an App-Specific Password, which you can set up by following the steps found in the window that appears when the associated Setup button is clicked.

Once everything has been setup, the notarization process will happen the next time the app is built. Note, the notarization process will not take place when the app is debugged from the IDE (as with hardened runtime); you don’t need to specifically disable that option.

Entitlements

The combination of certain certificates, build, and distribution options you choose for your app may require you to set a series of entitlements; for example, when enabling sandboxing and/or hardened runtime. Additionally, with Xojo 2026r1 it is possible to attach your built or debugged apps to Xcode Instruments for further inspections beyond the current capabilities of Xojo’s debugger.

In all of the above scenarios, Xojo will take care of the required entitlements without you needing to notice it; but if your app also makes use of some features that require adding extra entitlements (and probably a matching provisioning profile), as happens with most of the Apple specific services such as iCloud, Keychain, In-App Purchases, etc., you will need to craft the corresponding .plist file for them and add it using the User Entitlements option. These entitlements will be combined with the ones automatically generated by Xojo and included in the app during the code signing process.

Provisioning Profiles

On macOS, provisioning profiles are supported by a Copy Files build step, which requires selecting Contents as the destination folder. Not ideal, but that way you can select what kind of provisioning profile you want to apply to builds or when debugging your project (this is a new feature starting with Xojo 2026r1).

Property List Editor

The ability to add your own property list entries to the compiled/distributed macOS app is enhanced by a complete Property List Editor available under Build Settings > macOS since Xojo 2025. It makes it easier to create these entries and even save them for reuse in other projects.

The entries you add with the Property List Editor will be combined with those automatically generated by the IDE, or with entries that may have been added to the project using previous methods (such as adding an external .plist file to the Project Navigator sidebar).

Publishing to the Mac App Store

While there are some steps that need to be done both at Apple’s Developers Portal and App Store Connect Website, you will be able to set your app category directly from the IDE under Build Settings > macOS.

In addition, the Publish feature (responsible for sending your app to App Store Connect) will be in charge of verifying that the project meets everything that Apple requires prior to send it for reviewing or making available through TestFlight.

In order for the Publish button to be enabled, you need to select the App Store option for the selected “Developer ID” Team from the “Build For” popup menu under Build Settings > macOS > Sign.

Dealing with Certificates Issues

It doesn’t matter if your app requires entitlements, provisioning profiles, or if you are going to notarize it or enable sandboxing plus hardened runtime. All of this is based on the signing of your developer certificates, so let’s go back and see how to deal with the most common issues related with these.

Backup Your Certificates

Once you have installed your certificates, the first thing you should do is export them from Keychain Access to a secure place (ideally, not in your computer but an external USB key or drive). Why? Here’s why:

Apple only allows you to create certificates a maximum of five times per year (mostly because they expire after one year, as we did see in a previous entry). Every time you install certificates, whether on the same computer or a different Mac you own, they count as new certificates, with different serial numbers and SHA1/SHA256 data. In practice, this reduces the number of installations available per year.
In addition, some features, like provisioning profiles, rely on the specific certificates selected during their creation. You will get a signing error if you build the app on a Mac with different certificates.
If you need to restore your Mac or migrate to a new Mac, your certificates won’t be restored using the usual tools from Apple. Having a backup of your developer certificates will make easier to restore them in Keychain Access after restoring your computer or when you change to a new Mac.

Instead of using Xcode to install new certificates on every Mac you intend to use for code signing, install them on just one Mac, export them from that Mac, and import them into the Keychain Access app on your other Macs. This ensures all of your Macs will use the same certificates.

Review Pending Apple Developer Agreements

This is one of the most common issues related to code signing: it just stops working and you don’t know why and even the returned error messages doesn’t reveal why. If you’re sure you have the required developer certificates installed, they are valid (not expired), and don’t have any other issues then it is time to sign-in into the Apple Developer and App Store Connect portals to check if there are some pending agreements you need to accept.

Missing and Expired Certificates

This is another very common issue. Starting with Xojo 2026r1, we made easier to detect this situation. If a given certificate for your team is not installed, then you won’t be able to select the signing option from the “Build For” popup menu under Build Settings > macOS > Sign. You can further dig into it selecting the “Inspect…” option from the “Developer ID” popup menu, and even receive some advice on how to fix it!

Certificates are all good… but the signing throws errors

When using the Direct Distribution or App Store options, the code signing process uses Apple Time Servers to add the date and time as part of the signing. That means that the computer requires an active Internet connection, and that such time servers must be reachable from Apple’s side (it’s very rare for them to be down).

Other operations such as notarization and publish also require an active Internet connection, and the corresponding Apple services must be up and running. Some times these can be down.

When these issues occur, it is a good idea to check the Apple Services status webpage.

In summary

It’s been a long four-article ride with the aim of giving you a clearer understanding of what happens under the hood when you code sign your macOS apps, what kind of certificate you need for a given distribution, and which macOS security features are supported by Development, Developer ID Application or Apple Distribution certificates; and, most importantly, how Xojo helps you with all of it!

I’d love to hear about your experience with macOS code signing, the rough corners you still need to tackle, and other improvements you would welcome. The Xojo forums are a great place to keep the conversation going!

Happy macOS code signing with Xojo!

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.

Code Signing on macOS: What Developers Need to Know

Custom Control Rendering with DrawControlInLayoutEditor

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

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

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

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

Why this matters

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

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

How it works

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

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

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

A note about XojoScript limitations

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

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

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

Support for more Graphics

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

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

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

Class LinearGradientBrush

  Sub Constructor()

  Sub AddStop(stop As Double, c As Color)

  Property StartPoint As Point
  Property EndPoint As Point

End Class

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

Turning off this feature

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

Finally

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

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

Team-based Signing Arrives to macOS

Javier Menendez — Tue, 31 Mar 2026 13:21:00 +0000

In Xojo 2026r1 we revised the macOS Developer ID field and replaced it with a Team-based popup menu that aligns with the style found in iOS projects. This change aims to offer a cleaner, more intuitive way to manage developer certificates for the distribution of your built macOS app.

The Developer ID field was introduced in Xojo 2022r1, allowing you to fill in the developer certificate information needed for signing built macOS apps; however, it could be confusing to know exactly what information was expected.

Developer ID Application
Developer ID Application: Francisco Javier Rodriguez Menendez
Developer ID Application: Francisco Javier Rodriguez Menendez (BW7PU32485)
7D767DB917A45A8976BEB5B92F04E8C18D09501A

And… which certificate should be used for Development builds, Direct Distribution, or Mac App Store publishing? That may not be obvious for someone new to all this.

Additionally, what happens if the entered data comes from an expired certificate or if the certificate isn’t in the Keychain?

The new approach: How it works

The Team-based signing chooser for the Mac Developer ID field follows these steps:

Collects all the developer certificates found under the user Keychain.
Groups the valid certificates by Team (what Apple designates as the TeamID).
Based on the previous information, the new popup menu “Build For” will offer only the code-signing options available for the current selected Team:
- Development. This is the equivalent to using the Apple Development certificate.
- Direct Distribution. This is the equivalent to using the Developer ID Application certificate.
- App Store. This is the equivalent to using the Apple Distribution certificate. In addition, the Publish feature will be enabled if, for the selected Team, there is also a valid 3rd‑party Mac Developer Installer certificate available.

If None is selected in the Developer ID popup menu, the macOS app will be built/debugged using Ad-Hoc signing.

Both menus update on the fly, so if new certificates are added (or removed) from the keychain, or if any have expired since last opened, both the Developer ID and Build For popup menus will reflect those changes.

macOS Certificates Inspector Window

Under the Teams popup menu, there is also an Inspect… option. When selected, it opens a new window where you can view and gather additional information for:

Installed / Missing Apple Intermediate Certificates.
Installed / Missing / Expired Developer Certificates, grouped by Team.

At a glance, you’ll see useful details for each certificate, such as:

The expiration date
The keychain where it is stored.
Serial number, useful for identifying same-kind developer / intermediate certificates under different Macs.
Issuer specific information.

Clicking any certificate provides more detailed information about the role it plays in the macOS signing process.

This Inspector is also useful in order to identify some of the most common issues related with the handling of certificates such as:

Missing certificates for a given Team, determining thus the options that are available under the “Build For” popup menu.
Expired certificates. These also determine the options that are available under the “Build For” popup menu for a given Team. In addition, if you want to do some cleanup, it is possible to delete these expired certificates directly from the Inspector without needing to open the Keychain Access app.
About to expire certificates, so you are aware of it and the impact it could have on apps close to be distributed or on already created Provisioning Profiles, for example.
Certificates with their private key missing. These can’t be used for signing purposes, so you will be able to re-install them in the keychain (if you have a backup) or install a new certificate.
Developer Certificates where some of the required intermediate certificate is missing. You will be able to install the missing Intermediate (active Internet connection required).

Improvements to macOS Builds and Debugged apps

Although Sandboxing, Entitlements, and Provisioning Profiles have been part of macOS app development, this release brings several enhancements in these areas:

Now it is possible debug Sandboxed apps directly from the IDE.
Entitlements and Provisioning Profile are applied when the app is debugged from the IDE.
Improvements in how the required Entitlements are added and signed when the macOS app is built; and also a better handling of the user-added entitlements and provisioning profile files (if required).
Debugged and Built apps can be attached to the Instruments app. Among other things, Instruments can be used to detect issues such as memory leaks in the executed app. The IDE now automatically adds the required entitlement for this when: the app is debugged/built using the “None” (Ad-Hoc signing) from the Team popup menu, or, 2) when the app is built for Development (Build For) for a given Team.

When Build For is set to Direct Distribution or App Store, the required entitlement for Instruments to attach to the app, will be added only when the app is debugged from the IDE. If you want to use Instruments with a built app signed using these certificates, then you need to add that entitlement explicitly.

This decision is because when get-tasks-allow is set to True (the entitlement required in order Instrument being able to function), there are some well documented vulnerabilities that could be used to escalate privileges or inject code into your app. That’s not desirable for your distributed apps for sure (whether using Direct Distribution or if your app is installed through the Mac App Store).

Looking forward

We know there are still some areas to improve regarding code signing on macOS (and iOS) and we are working on some of them already. In the meantime, you’ll likely find the new Team-based Developer ID option more approachable, especially if this is your first experience dealing with certificates, signing, and distributing your freshly built macOS app.

A big THANK YOU to Richard Grafl for all his help and feedback during the beta-testing cycle of this feature.

Happy macOS code-signing!

Learn more about Code Signing in our recent series:

Code Signing on macOS: What Developers Need to Know

Code Signing on macOS: What Developers Need to Know, Part 3

Javier Menendez — Tue, 24 Mar 2026 16:00:00 +0000

If you followed the previous two articles in this series, you should be set up properly now, right? Your Mac developer certificates are stored in Keychain Access, so you only need to fill in the Developer ID field under Build Settings > macOS > Sign with the appropriate certificate value, click Build (or Publish), and distribute your new amazing app worldwide. Well, not quite. There are still other pieces to consider when signing and distributing your macOS app.

For the past 20 years, Apple has increasingly tightened security measures when it comes to running apps distributed by third parties. Let’s take a look at this summarized timeline of code-signing and security measures added by Apple over years:

The most notable developments happened in 2011, 2012 and 2018, when terms like Sandbox and, especially, Containers, Gatekeeper, Hardened Runtime and Notarization were introduced and began to impact other pieces of the puzzle to consider when signing macOS apps. In fact, we could say that technologies such as code-signing, Sandboxing, Entitlements or Provisioning Profiles were among the first iOS technologies to make their way to macOS.

So here is an broad overview what these technologies mean:

Sandboxing– When used, Sandboxing confines applications to a restricted, designated area of the system (its own “container”), preventing them from accessing user data, hardware or other apps without explicit permission. The system requires apps to ask for permission to use hardware resources or access user files. Sandboxing is mandatory for apps distributed through the Mac App Store.
Gatekeeper- This technology is the primary security layer that checks whether a downloaded app comes from a verified/known developer, especially when the application has been Notarized by Apple.
Hardened Runtime– Acts as a proactive, system-enforced shield that protects applications while they run, preventing malicious code from exploiting legitimate software. Enabling Hardened Runtime is required for Notarization.
Notarization– Notarization is an automated security screening process run by Apple that scans software distributed outside the Mac App Store for malicious components and known security issues. Today, notarization is required for software distributed outside the Mac App Store that has been signed with the Developer ID application certificate. As a result of the process, notarization generates and staples a ticket, signed by an Apple certificate, to the app so Gatekeeper can trust it when executed.

So, basically, while Sandboxing is still optional for apps distributed outside the Mac App Store (i.e., signed with your Developer ID certificate), Notarization and Hardened Runtime are the recommended defaults. Enabling Sandboxing for your app is something you should consider based on the needs (features) and the privacy balance you want to offer your users.

If you plan to distribute the app through the Mac App Store as well, it will need to be Sandboxed and signed with your Apple Distribution certificate, while enabling Hardened Runtime is optional.

Entitlements and Provisioning Profiles

Entitlements and Provisioning Profiles are also required for many of these security measures, depending on the features and services your app uses, and they come into play during building and signing.

If you decide to go the Sandboxing route, then using Entitlements is mandatory. The good news is that Sandboxing entitlements are free to use (they don’t require creating or adding a Provisioning Profile to the project). However, if your app needs special access to the Keychain or uses iCloud, Apple Pay, or other services, you’ll need to create a Provisioning Profile in the Apple Developer portal.

Wait—what are Entitlements and Provisioning Profiles, and how do they relate to macOS app code signing?

Entitlements

Entitlements are XML-based .plist files (not unlike the app’s Info.plist) containing a set of key-value pairs. They are embedded directly into the app’s binary as part of the code signing process, typically using your Developer ID Application or Apple Distribution certificates.

Provisioning Profiles

While Entitlements are just a file, Provisioning Profiles are a different beast:

Provisioning Profiles must be created in the Apple Developer Portal. When you create one, you specify the App ID (the combination of your Team ID and the app bundle identifier which are case sensitive so pay attention). Even if you don’t plan to distribute your macOS app via the Mac App Store, you still need a Provisioning Profile, which requires creating an App ID first in the Developer Portal.

There are two kinds of Provisioning Profiles: Development and Distribution. As part of the provisioning profile creation, you must choose which type you will use.

Development Provisioning Profiles are used while you’re developing your app; the app is signed with an Apple Development certificate and is intended to run on a set of Mac computers you’ve registered. During creation, you can add as many Apple Development certificates as you have under your Team ID.
Distribution Provisioning Profiles are used when distributing your app. For direct distribution, sign with the same Developer ID certificate you’ll use for signing the app; for Mac App Store distribution, sign with the Apple Distribution certificate.
Development and Distribution Provisioning Profiles do expire. This is something to keep in mind, especially when deploying new or updated versions of your app, because you may need to create new profiles.
Development and Distribution Profiles are editable. If you make a mistake, note that both types can be edited in the Apple Developer portal, but only for certain fields: the App ID, the profile name, the selected certificate, and (for Development profiles) the included testing devices.

When Certificates and/or Provisioning Profiles expire…

We’ve already noted in previous articles that Apple Developer certificates expire one year after they’re created. We’ve also learned that if your app relies on a Distribution Provisioning Profile, that profile can expire as well. So, what does this mean for your already deployed apps?

No worries. Let’s focus first on directly distributed macOS apps (those signed with the Developer ID certificate) and pull one screenshot from the previous article:

Observe the highlighted Timestamp line. When the app is signed, the date is added automatically (retrieved from Apple’s servers). So, when a user runs an app whose embedded Developer ID Certificate has expired since its release, Gatekeeper will rely on that timestamp, compare it to the embedded certificate’s expiration date, and if everything matches—meaning it was signed before the certificate expired—the app will continue to work, provided the embedded certificate has not been revoked by the developer. In addition, if the app was Notarized, that helps a lot, because the stapled ticket includes its own timestamp and was signed with a longer-lasting Apple Certificate.

If the app is distributed through the Mac App Store, there’s good news. After you submit the app for distribution via App Store Connect and it passes Apple’s review, the app’s signing with your Apple Distribution certificate is replaced by Apple’s own signing. This means that users who install the app from the Mac App Store can continue to run it even if your original Apple Distribution certificate expired long ago.

Distribution Provisioning Profiles behave differently from others: once they expire, the app containing such a Distribution Profile will fail to execute.

The good news is that a Distribution Profile lasts for a very long time (around 18 years) so you’ll likely have ample time to create new distribution provisioning profiles and deploy updates that use renewed profiles well before users are affected.

Of course, as soon as any of your Apple Developer certificates expire, you already know how to request and install new ones in your Mac keychain.

Nearly Concluded

In the next, and last article, we will see how Xojo helps with everything related to signing and distributing your macOS apps. I’ll also show you how to deal with some of the most common issues related with certificates.

Code Signing on macOS: What Developers Need to Know

Scatter Chart: Connecting the Points

Javier Menendez — Mon, 09 Feb 2026 16:26:56 +0000

A user recently asked whether it’s possible to connect the (x, y) points in a Scatter chart using DesktopChart, and if so, how to do it. The short answer is yes, it is possible. Read on and I’ll show you just how easy it is.

For this example, we’ll use the x and y coordinate values of the sine and cosine functions as the data for our scatter DataSets. Go ahead and create a new Desktop project in the Xojo IDE.

Next, select the default Window1 and drag a DesktopChart control from the Library panel into the Layout Editor for Window1. Adjust the right margin to the recommended right layout guide, then lock the Top, Left, and Right layout locks for the Chart1 instance using the Inspector. At this point, your design should look similar to this:

While you’re there, select Chart1 and, in the Inspector, set the option Behavior > Mode to Scatter.

Next, with Window1 selected, add two properties using the following values:

Property 1:

Name: CosStyle
Type: ChartLinearStyle
Scope: Private

Property 2

Name: SineStyle
Type: ChartLinearStyle
Scope: Private

These properties will be used to store references to the Style objects associated with the cosine and sine function DataSets.

Finally, with Window1 still selected, add the Opening event and enter the following lines of code into the associated code editor:

CosStyle = New ChartLinearStyle
CosStyle.Line = ChartLinearStyle.LineTypes.Dashed

SineStyle = New ChartLinearStyle
SineStyle.Line = ChartLinearStyle.LineTypes.Solid

DrawScatterChart

In brief, this code creates new ChartLinearStyle instances for the properties added earlier. It assigns a solid line style to connect the cosine function data points and a dashed line style to connect the sine function data points. After that, it calls the DrawScatterChart method, which is responsible for rendering the sine and cosine functions on the Chart1 instance.

Now, let’s create that method on Window1 using the following values in the Inspector:

Name: DrawScatterChart
Scope: Private

Type the following snippet of code in the associated Code Editor for the method:

// These are the Array variables in charge of storing the Scatter data points
// for the Sine and Cosine functions
Var sinePoints() As ChartScatterDatapoint
Var cosinePoints() As ChartScatterDatapoint

// …and these variables will handle the DataSet instances
// for the previous arrays of data points on both functions
Var sineDataSet As ChartScatterDataset
var cosDataSet As ChartScatterDataset

Const pi = 3.14159265359
Var y As Double
Var maxXValue As Double = 2.0 * pi

// Using a simple loop to feed the x and y
// values for the Sine and Cosine
For x As Double = 0.0 To maxXValue Step 0.5
  
  y = Sin(x)
  sinePoints.Add(New ChartScatterDatapoint(x, y, 1))
  
  y = Cos(x)
  cosinePoints.Add(new ChartScatterDatapoint(x, y, 1))
  
Next

// Next, we create the new instances for the Scatter DataSets
sineDataSet = New ChartScatterDataset(Color.Blue, sinePoints)
cosDataSet = New ChartScatterDataset(color.Red, cosinePoints)

// …and we set the Style to be used on each of them
sineDataSet.Style = SineStyle
cosDataSet.Style = CosStyle

// … and of course the labels to be shown on the Legend section
// of the chart itself
sineDataSet.Label = "Sine Function"
cosDataSet.Label = "Cos Function"

// As the last step, we add both DataSets to the chart
// so these can be rendered
Chart1.AddDatasets(sineDataSet, cosDataSet)

Run the app, and it should look similar to this:

A change of Style… on the fly!

As with many aspects of DesktopChart, any changes made at runtime are reflected immediately, without the need to redraw the chart, re-feed the data sets, or perform any other complex operations. Let’s take advantage of this by changing the sine and cosine styles at runtime, allowing users of our example app to toggle whether the points are connected.

Add two DesktopCheckBox controls below the bottom margin of the Chart1 instance on Window1. Set the Caption of the first checkbox to “Connect Sine Points” and the second to “Connect Cos Points.” For both checkboxes, use the Inspector to set Initial State > Visual State to Checked.

The final layout should look similar to this:

Lastly, add the ValueChanged event to both CheckBox instances. Then, for the checkbox with the caption “Connect Sine Points,” add the following lines of code to its event handler:

If Me.Value Then
  SineStyle.Line = ChartLinearStyle.LineTypes.Dashed
Else
  SineStyle.Line = ChartLinearStyle.LineTypes.None
End If

Add the following lines of code to the ValueChanged event handler for the checkbox with the caption “Connect Cos Points”:

If Me.Value Then
  CosStyle.Line = ChartLinearStyle.LineTypes.Solid
Else
  CosStyle.Line = ChartLinearStyle.LineTypes.None
End If

Run the app again and, this time, click each checkbox to see how the points are no longer connected when a checkbox is unchecked, and are connected when it is selected.

Summary

As you can see, styles can be used not only to connect points in a Scatter chart, but also to customize the point endpoints beyond the default appearance. For example, you can set the endpoint to “None” or choose from many other available options. Even better, any changes made to a style at runtime are applied immediately.

Xojo + XAML + Goto = 🔥

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

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

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

At a high level, the workflow looks like this:

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

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

Visual States in XAML

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

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

Example XAML

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


  
    
      

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

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

      
    

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

In this XAML:

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

Triggering the Transition from Xojo

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

XAMLContainer1.GotoState("Top")

And to move it back down:

XAMLContainer1.GotoState("Bottom")

Why This Is Powerful

What makes this feature especially useful is that:

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

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

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

XAMLContainer1.GotoState("On")

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

Tip: Customize Toolbars on macOS apps

Javier Menendez — Wed, 17 Dec 2025 17:04:00 +0000

Starting with Xojo 2025r3, macOS apps are built using macOS SDK 26. One benefit of this is that your apps automatically gain access to newer native macOS features with little or no extra work. In some cases, these features are available immediately; in others, they can be enabled with a simple Declare. One such example is allowing users to customize an app’s toolbar.

To demonstrate this, we’ll use the Desktop Toolbar example project that ships with Xojo. You can find it in the Examples section of the New Project window. Open this project using the Xojo 2025r3 IDE.

Once the project is open, locate the MainWindow in the Project Browser. Under MainWindow, select the WindowToolbar item and then choose its Opening event. At the top of the Code Editor for this event, add the following lines of code:

Var hdl As Ptr = Me.Handle
If hdl.Integer <> 0 Then
  Declare Sub AllowCustomization Lib "AppKit" Selector "setAllowsUserCustomization:" (hdl As Ptr, value As Boolean)
  AllowCustomization(hdl, True)
End If

It’s that simple!

Run the app and open the contextual menu by right-clicking (or Control-clicking) on the window’s toolbar. You’ll see a new Customize Toolbar menu item. Select it to open the standard macOS toolbar customization panel, where you can rearrange or remove items as you like. When you click OK, your changes are immediately applied to the current toolbar.

One important caveat: these customizations are not preserved between app launches. This happens because each toolbar must have a unique identifier that macOS uses to save and restore its configuration. Since the example toolbar does not provide one, the OS has nothing to store or retrieve. But… who knows what the future holds?

Toward the Future with WinUI

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

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

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

What can you look forward to in 2025r3?

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

What are the benefits of using WinUI?

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

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

Compared to the WinUI version with a colored emoji.

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

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

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

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

A Win32 DesktopComboBox which does not support separators.

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

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

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

Win32 dark mode support is limited.

WinUI dark mode support is easier on the eyes.

The Win32 DesktopMoviePlayer is very dated.

WinUI has a much more modern look and feel.

Opt-in to WinUI

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

More Work Ahead

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

Welcome to the Grid

Javier Menendez — Tue, 09 Dec 2025 16:29:53 +0000

Xojo 2025r3 introduces the first iteration of the DesktopGrid control. This long-awaited control allows you to display as many rows and columns as needed, making it ideal for complex data layouts. Let’s take a closer look at some of its features.

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.

Checking Out Xojo Libraries

Paul Lefebvre — Tue, 09 Dec 2025 16:29:31 +0000

The ability to create a compiled Library with Xojo has been a long-requested feature. Starting with 2025 Release 3, Library support is now available as a preview. Here’s more information about what it is and how you can use it.

What is a Library?

A Library is a collection of pre-written, reusable code containing methods, classes and UI. Up until now, the way to distribute a Library for use with Xojo was to create a Plugin or to manually re-use project items across projects. Both have pros and cons.

Plugins are compiled and do not expose source code, but plugins cannot be created using Xojo itself and are typically created using C/C++ along with the Xojo Plugin SDK. Sharing project items is fine for internal projects or open-source projects, but less ideal for commercial libraries. They can be harder to manually add to a project and are recompiled along with the project, slowing the debug process.

With a Xojo Library, you can now create your own compiled Library using Xojo itself. This Library can contain nearly any Xojo project item and can be easily used in other Xojo projects because it is distributed as a single file.

At a high-level, you create your Library in Xojo, add your project items to it and built it into a Library package file. Other projects can then use this Library package, which gives them access to the items you included in the Library.

Creating a Library

Here is a brief overview of how you create a Xojo Library:

In a Desktop, Web, Console or iOS project add a Library by choosing Insert->Library.
Add the project items you want to the Library. Any Xojo project item is supported, except for Worker.
Build the project. It will build the main app (which should serve as a test app for your Library) and a separate Library package file (with extension .xojo_library).
You can put this Library package alongside another project (on the drive) and it will be loaded when that project is opened by Xojo. You can then use the classes, methods and UI contained in the Library within your project. If you instead put the Library in the Plugins folder, then it will be available for all projects.

This is all best demonstrated by a quick example. Go ahead and create a Desktop project and add a Library to it, which adds a Library1 project item to the Navigator. Change its name using the Inspector to LibHello.

While LibHello is selected, choose Insert->Class. This adds Class1 to it. This new class is now part of the Library. With Class1 selected, change its name to StringStuff.

You can now add whatever methods or properties you want to the class. For our example purposes here we will add a simple method that reverses a string.

Public Function ReverseString(s As String) As String
  Var newString As String
  
  For Each c As String In s.Characters
    newString = c + newString
  Next
  
  Return newString
End Function

The Library could contain many other things of course, but to keep things simple this Library will have just the single class with its single method. Here’s what it looks like in the project:

The first thing to do is to test this Library ReverseString method. Add a button to Window1 and have it call the function, verifying the result.

Var stuff As New StringStuff
Var result As String = stuff.ReverseString("Xojo")

MessageBox(result)

When you run, you can see the output:

So far this is all not much different than you would normally be doing with a Xojo project. The next step is to create the Library package for use by other projects.

In the Build Settings area, select Shared. This is where you can enter some information about the Library that can be seen by those that use it.

In the Version field, enter “1.0”.
In the Copyright field, enter “Acme, Inc.”
In the Description field, enter “A Xojo Library test.”

Also in the Build Settings area, check the boxes for the platforms you want the Library to work on. In most situations, you will want to select macOS, Windows and Linux.

Now click Build. This builds the app as usual, but also creates a separate Library package file (LibHello.xojo_library for this example) that can be used with other projects.

Using a Library

Now that you’ve created your Library package, you can use it with other Xojo projects. The Library built above was created within a Desktop project, so it can only be used with other Desktop projects. So the first thing to do is to create a new Desktop project (call it MyTest), save it and close it.

Once it is saved, go to Finder or Explorer and place a copy of the LibHello.xojo_library file (from its build location) alongside this saved project file.

Go back to Xojo and open the MyTest project. The project will open normally, but the Library will also be loaded up as well. You can see this by showing the Xojo About window and going to the Plugins & Libraries tab. There you will see the Library name along with the information you entered about it earlier. (Double-click on the Library row to show the description.)

Going back to the MyTest project, you can now use the Library with it. Add a button to the window and have it call the StringReverse function the same way you did before:

Var stuff As New StringStuff
Var result As String = stuff.ReverseString("Xojo")

MessageBox(result)

Now run the project and it will use the class and its method just as if it is part of the project.

That’s the basics of how to create and use a Library. You can of course include whatever you want in the Library, but as with any library it is usually a good idea to keep things well-organized.

Considerations

A Library package (which uses ZIP) contains compiled code and definitions of the public API in that code.
Only a single Library project item can be added to a project when developing.
A project can use any number of Library packages.
For a built library to work on all OS platforms, then those platforms must be selected before building it.
Libraries only support 64-bit builds.
Library packages are placed alongside the project file and are loaded when the project is loaded.
Library packages can also be placed in the Plugins folder. These libraries will be loaded separately for each project.
If items in your Library have dependencies outside the Library, then the Library package will not be usable in another project without those dependencies. For example, if a Library class method references a class in the main project, then it will build without an error (because the main project is available), but if you use that Library in another project you will get linker errors.

Why a Preview?

We are referring to this initial version of Xojo Libraries as a preview release because it is very new and we want to give more developers a chance to test with it so we can iron out issues. We encourage you to try moving your existing reusable code collections over to a Library to help test, while also improving your workflow. If you have any open-source projects that are essentially a Library, you might try building them into a Xojo Library package as well.

You can make Library packages available publicly, but you should probably tag them as a preview, beta or test version until we remove the preview label.

Read more about Libraries in the Xojo Documentation. Check out these open-source projects on GitHub that have recently been updated for API 2.0 and now have a Library that you can download from the Releases section:

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.

Year of Code 2025: October Project – Multi-Platform Communication

Gabriel Ludosanu — Mon, 13 Oct 2025 19:01:53 +0000

For October’s Xojo Year of Code 2025, I built MPACSocket, a tiny, reusable UDPSocket subclass that enables zero-config, local-network presence and chat across platforms. It wraps binding, broadcast, presence beacons, peer tracking, and JSON parsing into a single class with a clean event-based API. Drop it into Desktop projects and you’ve got instant LAN discovery and messaging.

What this project includes

A self-contained UDPSocket subclass (MPACSocket) that handles bind, presence broadcasting, peer pruning, and chat envelopes with versioned JSON (good for further updates to the protocol).
Simple API: Start(port), Stop(), Rename(name), SendChat(text). Everything else comes through events like Bound, ChatReceived, PeerOnline/PeerOffline, PeerUpdated, StatusChanged, and SocketError.
A sample DesktopWindow (wndMPAC) that wires MPACSocket to a transcript area and peers list.

How to use

Add MPACSocket to your project, drop it onto a DesktopWindow or instantiate in code.
Set DisplayName, call Start(62636), and listen to events to update your UI or console output.
Use SendChat to broadcast a message; presence beacons and peer tracking happen automatically.

Download

You can download the entire Xojo project from GitHub

This project shows how a small, well-scoped class can turn low-level UDP into a friendly, cross-platform building block. Feel free to adapt the events or JSON schema for your own protocols.

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!

Year of Code Project

How to Play:

Each month we’ll announce a new theme and share an example project of our own. Share your projects to the Xojo Forum thread for that month via GitHub (all the links you need are posted above ↑ ). Learn how to use Xojo and GitHub.

The Prizes:

Monthly winners get $100 at the Xojo store. Every month you submit a project is another chance to win the grand prize. The grand prize is $250 cash plus a Xojo Pro license and a year of GraffitiSuite and will be announce in December. Learn more about the prizes.

Spotlight On: Aaron Andrew Hunt

Alyssa Foley — Fri, 10 Oct 2025 02:00:00 +0000

Spotlight On posts focus on Xojo community members. We’ll use this space to tell the stories of people using Xojo, share amazing Xojo-made apps and spread awareness of community resources. If you have an app, a project or a person you want to see featured in Spotlight On, tell us about it!

Aaron Andrew Hunt has used Xojo for over 20 years. Recently, he and Geoff Perlman got into a conversation about their shared love of music and coding. Aaron is a composer who uses Xojo (along with MBS plugins) to develop desktop apps for music and publishing. He also creates bespoke music-related apps, in fact, he has been collaborating with a UK-based composer since 2012 on an intensive music database app.

Mac, Windows or Linux?

I’ve been a Mac user since the 90’s, and Xojo lets me write software on the Mac, then port that with minimal effort to Windows. Linux has never held enough incentive for me, but Xojo works on that too. There are obvious differences between the platforms, but Xojo minimises them. Porting code from Mac to Windows sometimes includes a bit of tweaking on Windows, but in many cases it’s a matter of minutes. There have been a few times I’ve developed on Windows and then ported to the Mac. It’s a big plus that Xojo lets us use whichever platform we prefer, and switch platforms easily.

How would you explain your most recent project to a new developer?

My most recent project is protected under a strict NDA, so I’m afraid I’m not allowed to explain it to anyone!

What’s on your “Learn Next” list?

A large part of coding is fairly simple logic, but a project of any complexity is going to present problems that will lead to learning something new, or sometimes re-learning something long forgotten. That learning aspect is one of the most attractive parts of the work for me. I make task lists, but “learn this or that” usually isn’t on the list; I write down the goal, and if I’m able to reach that, it means I’ve learned what I needed to know.

How did you find Xojo? And when did you start using Xojo?

By my count I’ve been using Xojo for 23 years. I had just started a new job teaching at a University, and my mentor, a senior colleague in the department, introduced me to REALBasic. He knew I had been looking for a tool to write music software for the Mac, and RB was relatively new and gaining notoriety. A few years before this I had been using the quirky graphical programming tool called Max (which later became Max/MSP, similar to PureData) on macOS 9. I had learned Max well enough to do some pretty impressive things with it, but I didn’t like because there was no code! Or precious little. Once I started with RB, it took me a while to adjust my antiquated linear thinking to an event-driven object-oriented model, but once enough light-bulbs went off, I was happily coding away (and I never went back to Max).

What did you first build with Xojo? And when was that?

My first projects were ports of the apps I had written in Max, for microtonal music. I also wrote several apps to demonstrate things in the classroom, for example a sprite-based app with a video-game-like feel called The Tonal Solar System, where triads and seventh chords appear as planets orbiting around a tonic sun, and chord progressions happen by “activating” planets in a particular order. It supported inversions and alterations and had some pretty advanced functions. The graphics were nothing spectacular, somewhat similar to the kinds of games I had made as a kid on the Commodore 64. The more serious tools for microtonal music were the beginnings of what later became my business, H-Pi Instruments (https://hpi.zentral.zone) where software works in combination with microtonal hardware I designed with my business partner Jordan Petkov in Bulgaria. There was a microtonal keyboard I designed called the Tonal Plexus, and a micro-tuning device called TBX1, which later became TBX2, and TBX2b. These all worked with apps built using Xojo and the MBS plugins for cross-platform MIDI and audio functions. The Xojo / MBS combination allowed me to develop these apps relatively quickly and easily without getting bogged down with the kinds of management tasks other tools require.

What do you build with it now?

I still maintain and occasionally expand the capabilities of apps that have long histories going back decades. Some more recent projects include PDF Bookmaker a self-publishing tool, MIDI Router a tool for managing and scripting MIDI traffic on desktop macOS, and MIDI Tapper an assisted performance tool for making realistic-sounding recordings by “tapping” through MIDI files using just one or two MIDI keys rather than having to play all the right notes in the conventional sense. These are all apps I developed for my own needs, which I also use on a regular basis. Features are added at customer request, and also whenever I need the app to do something it doesn’t do yet.

MIDI Router is essential for my work – it’s always running in the background, with scripts that solve specific quirky hardware problems in my setup. I use PDF Bookmaker every time I publish a new score, and MIDI Tapper to make quick recordings for myself and for my students. The latter is a really powerful app with a small but enthusiastic user base, which deserves to gain a wider audience (marketing is not really in my skillset). The concept is based on the graphical music animation work of Stephen Malinowski https://www.youtube.com/@smalin.

Do you earn a living with Xojo?

My focus at this point is on writing music and teaching private students, but software sales and hired coding work have definitely been an important part of my livelihood for a long time now, and Xojo is the essential tool for those things. It’s hard to imagine being where I am today without Xojo. I’ve stuck with it because of its consistency and reliability, its friendly management, and the forum, with its very helpful user-base. My licenses will continue to be renewed after retirement. I plan to keep on using it as long as I’m around.

Do you use it for any hobbies?

I use Xojo for all kinds of things for my own private use, not intended for sale (though sometimes such projects do develop into something I eventually offer for sale). Being able to try out ideas and solve practical problems by writing my own apps is a beautiful kind of private joy. An app for exploring Gematria? Prime numbers? Bit-shifted integer encodings? Why not? It’s all fun stuff.

I’ve written many apps to do specific things when I needed some problem solved. Others might search the app store to find a tool they need. Nerds write their own. I wrote my own password manager, for example (why worry about trusting anyone else’s tool with my passwords?) Xojo makes coding easier than any other tool I’ve tried, and for me that’s very important. I don’t want to be fighting with the tool I’m using to try to do something creative. I want to have a pleasant time working as quickly as possible, and that’s basically what I get with Xojo and the MBS plugins.

What’s your biggest Xojo success?

An app called Universal Tuning Editor (UTE) is part of the biggest success I’ve had with my business, because it works in combination with all the hardware devices I’ve developed over the years, the latest being a mini-synthesizer I was able to make with the help of mitxela, called FLASH. This is the world’s smallest polyphonic microtonal MIDI synth, and it communicates with UTE over UART, using the Serial object in Xojo. I can use the UART port to communicate with the bootloader of the chip containing the synth firmware, or I can run that firmware and open the port at MIDI baud rate to control the synth through UTE. This combination lets users program their own patches and upload tuning tables to the synth, which they can then plug into any standard MIDI controller – without a power supply! UTE uses Xojo’s Object2D for scalable, rotatable vector graphics, with XML-based scripting so users can design their own interfaces. Xojo does an amazing job keeping up with the rapid changes in the industry, so I know as long as I do my part, my existing apps will continue to work. If I work on my coding as hard as they do, who knows, some new success could be right around the corner.

Thank you to Aaron Andrew Hunt for answering questions and sharing his Xojo experience with the community. You can see all his programs at https://hpi.zentral.zone.

If you have an app, a project or a person you want to see featured in Spotlight On, tell us about it!

How To Create a Custom Button Control in Xojo – Part 5: Adding Text Alignment

Gabriel Ludosanu — Wed, 08 Oct 2025 15:54:00 +0000

In our previous installment, we successfully wired up keyboard focus to our custom DesktopCanvas subclass, making it fully accessible and user-friendly.

Now, we’re going to tackle another key feature: customizable text alignment. By the end of this tutorial, you’ll be able to set the button’s text to align left, center, or right, and we’ll introduce a small amount of padding to keep the text from touching the edges when it’s not centered. This approach uses a strongly typed Enumeration to ensure we only accept valid alignment values, maintaining the high quality of our custom control.

1. Define the Text Alignment Options

To make our alignment property easy to use and type-safe, we will define a new enumeration inside the CanvasButton class.

Inside your CanvasButton class, go to Insert > Enumeration and add the following:

  Left = 0
  Center = 1
  Right = 2

2. Add New Properties for Alignment and Padding

Next, we need two new properties in the CanvasButton class to store the selected alignment and the padding value.

The TextAlignment property will use our new TextAlign enumeration, and, crucially, it defaults to TextAlign.Center.
The TextPadding property provides an adjustable inner margin, which is especially important for left and right alignment.

Public Property TextAlignment As TextAlign = TextAlign.Center
Public Property TextPadding As Integer = 8

3. Update the Paint Method

The core of this change happens in the Paint event handler. We need to modify the logic that calculates the horizontal position of the text (tx) to respect the value of our new TextAlignment property.

Locate the Paint event and replace the existing code with the following:

Sub Paint(g As Graphics, areas() As Rect) Handles Paint
  #Pragma unused areas
  
  // Use the custom CornerRadius property.
  Var currentCornerRadius As Integer = CornerRadius
  
  // Declare variables for the colors used in drawing.
  Var currentBgColor As Color
  Var currentBorderColor As Color
  Var currentTextColor As Color
  
  // Determine colors based on the button's current state (enabled, pressed, hovered).
  If Enabled Then
    If IsPressed Then
      // Use highlight color if pressed.
      currentBgColor = HighlightColor
      currentBorderColor = BorderColor
      currentTextColor = TextColor
    ElseIf IsHovered Then // Check for hover only if not pressed
      // Use hover color if hovered.
      currentBgColor = HoverColor
      currentBorderColor = BorderColor
      currentTextColor = TextColor
    Else
      // Use the custom background color for the default state.
      currentBgColor = BackgroundColor
      currentBorderColor = BorderColor
      currentTextColor = TextColor
    End If
  Else
    // Use appropriate system or standard gray colors for the disabled state.
    currentBgColor = Color.LightGray
    currentBorderColor = Color.Gray
    currentTextColor = Color.DisabledTextColor // Use system disabled text color
  End If
  
  // Set the drawing color and draw the background shape with rounded corners.
  g.DrawingColor = currentBgColor
  g.FillRoundRectangle(0, 0, g.Width, g.Height, currentCornerRadius, currentCornerRadius)
  
  // Set the drawing color and pen size for the border.
  g.DrawingColor = currentBorderColor
  g.PenSize = 2
  // Draw the border shape just inside the background rectangle.
  g.DrawRoundRectangle(0, 0, g.Width, g.Height, currentCornerRadius, currentCornerRadius)
  
  // Draw the focus ring
  If IsFocused And AllowFocusRing Then
    g.DrawingColor = Color.HighlightColor
    g.PenSize = 1
    g.DrawRoundRectangle(2, 2, g.Width-4, g.Height-4, CornerRadius-2, CornerRadius-2)
  End If
  
  // Enable anti-aliasing for smoother text rendering.
  g.AntiAliasMode = Graphics.AntiAliasModes.HighQuality
  g.AntiAliased = True
  // Calculate the width and height of the button text.
  Var tw As Double = g.TextWidth(ButtonText)
  Var th As Double = g.TextHeight
  // Calculate the X position to center the text horizontally.
  // Updated: compute X based on TextAlignment (Left, Center, Right) while preserving centered behavior as default.
  Var tx As Double
  Select Case TextAlignment
  Case TextAlign.Left
    tx = TextPadding
  Case TextAlign.Right
    tx = g.Width - tw - TextPadding
  Case TextAlign.Center
    tx = (g.Width - tw) / 2
  End Select
  // Calculate the Y position to center the text vertically, with a small adjustment.
  Var ty As Double = (g.Height + th) / 2 - 3
  // Set the drawing color for the text.
  g.DrawingColor = currentTextColor
  // Draw the button text at the calculated centered position.
  g.DrawText(ButtonText, tx, ty)
End Sub

The magic happens at line 60

4. Inspector Integration

If you want the alignment to be easily adjustable in the Xojo Inspector, you should expose the TextAlignment and TextPadding properties. For TextAlignment, because it uses an Enumeration, Xojo will automatically display a helpful dropdown menu with Left, Center, and Right options once you expose it through the Inspector Behavior editor.

Right-click the CanvasButton class in the Project Navigator.
Select ‘Inspector Behavior…’
Scroll through the property list and check the checkboxes for both TextAlignment and TextPadding.

Try It Out

You can now set the text alignment directly in the code or via the Inspector.

For example, to set alignment in code:

// Set the button to right-aligned text
MyCanvasButton.TextAlignment = CanvasButton.TextAlign.Right

Since the default value for TextAlignment is Center, no existing code needs to be modified, and all your current custom buttons will continue to render perfectly centered unless you explicitly change the alignment property.

Hope this update was useful.

You can grab the latest source on GitHub: GitHub – CanvasButton

More in this series:

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!

Implementing a Non-Blocking Image Processor with Xojo Threads

Gabriel Ludosanu — Thu, 28 Aug 2025 14:56:33 +0000

Have you ever written an app that needs to do some heavy lifting, like processing a big batch of files? Maybe you click a button, and suddenly your entire app just … stops. The cursor turns into a spinning wheel, the windows won’t respond, and your users are left wondering if it crashed. It’s a frustrating experience, but don’t worry, there’s a solution: Threads!

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:

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”.
DesktopProgressBar: This will give the user visual feedback on the progress of the resizing operation.
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 "/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:

Start the task from the main thread (ResizeThread.Start).
Work inside the thread’s Run event.
Communicate back to the UI with AddUserInterfaceUpdate.
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!

A XAML Driven UI

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

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

Migrating Towards XAML

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

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

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

A Deeper Dive into XAML

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

XAML is Asynchronous

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

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

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

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

Translating your XAML Experience

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

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

  angle = angle + 10

  If angle >= 360 Then angle = 0

  Var isChecked As Boolean = True

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

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

  XAMLContainer1.Content = xaml
End Sub

Child Controls Inherit the Parent’s Background Brush

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

Layering XAML

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

Setting Focus for Embedded XAML Controls

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

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

XAMLContainer1.Invoke("Button2.SetFocus")

Extended XAML Features

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

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

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

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

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

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

Having Fun With XAML

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

Windows Barcode and HTMLViewer Updates

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

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

Consistent Barcode Scanning Experience

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

DesktopHTMLViewer Improvements

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

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

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

A Guide to Managing Multiple Apple Developer Accounts in Xojo 2025r2

Javier Menendez — Tue, 08 Jul 2025 18:01:00 +0000

Usually, you only need to manage one Apple Developer Account when publishing your macOS or iOS apps. However, as many Xojo users have pointed out, there are situations where you need to work with multiple Apple Developer Accounts – perhaps you are publishing macOS apps for different companies (with different Team IDs). So, how do you handle this using the App Specific Password setup introduced in Xojo 2025r1?

The good news is that starting with Xojo 2025r2, you’ll be able to manage multiple Apple Developer Accounts! By default, everything will work just as it did in Xojo 2025r1. That means Xojo uses a global App Specific Password tied to the Apple Developer Account login (usually an email), the Team ID, and the password generated at appleid.apple.com.

So, if you don’t make any changes, everything will continue to work as before for your existing and new macOS projects published to the Mac App Store. But if you need to publish other macOS projects under a different Apple Developer Account or Team ID, you’ll need to create a new App Specific Password at appleid.apple.com (giving it a unique name), enter the new credentials in Xojo’s App Specific Password setup dialog, and then enable the “Save with Project” checkbox.

When you do this, the App Specific Password will be saved with the project itself, and its settings will be used whenever you click the Publish button.

If you ever need to switch back to using the Global App Specific Password for that project, select the “Global” option from the popup menu at the top of the same dialog.

And of course, don’t forget: if you’re publishing macOS apps using multiple Apple Developer Accounts, make sure all the necessary certificates for those accounts are installed in your Mac Keychain!

Thank you to everyone who provided feedback and suggestions about this feature!

How To Create a Custom Button Control in Xojo – Part 4: Adding Focus

Gabriel Ludosanu — Mon, 23 Jun 2025 22:35:31 +0000

In part 3 of this series we made our CanvasButton inspector-friendly by exposing all our colors, corner radius and other properties. Today we’re going to wire up real keyboard focus so that you can:

Tab to the button
See a neat focus ring when it has focus
Grab focus on click

1. Track the Focus State

Add a private property to keep track of whether the button has focus:

  Private IsFocused As Boolean = False

2. Respond to Focus Events

Implement FocusReceived and FocusLost so we can set/clear the flag and force a redraw:

  Sub FocusReceived()
    If Enabled And AllowFocusRing Then
      IsFocused = True
      Refresh(False)
    End If
  End Sub

  Sub FocusLost()
    If Enabled And AllowFocusRing Then
      IsFocused = False
      Refresh(False)
    End If
  End Sub

3. Grab Focus on Mouse Click

Modify your MouseDown to call SetFocus. Now clicking the button also gives it focus immediately:

  Function MouseDown(x As Integer, y As Integer) As Boolean
    #Pragma unused x
    #Pragma unused y

    If Enabled Then
      IsPressed = True
      SetFocus       // ← new
      Refresh(False)
      Return True
    Else
      Return False
    End If
  End Function

4. Draw an Inset Focus Ring

In the Paint event, after drawing the border, add:

// … after the border code …
If IsFocused And AllowFocusRing Then
  g.DrawingColor = Color.HighlightColor
  g.PenSize = 1
  // Inset by 2px so it sits inside the border
  g.DrawRoundRectangle(2, 2, g.Width-4, g.Height-4, CornerRadius-2, CornerRadius-2)
End If

5. Enable Canvas Focus

By default, DesktopCanvas won’t accept focus, so make sure to check AllowFocusRing in the Inspector when you drop CanvasButton onto a window.

Try It Out

Run the app:
- Tab to the button → you’ll see the focus ring

What’s Next?

Stay tuned for more awesome updates!

You can grab the latest source on GitHub: GitHub – CanvasButton

More in this series:

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!

Spotlight On: Sounds In Sync

Alyssa Foley — Wed, 11 Jun 2025 16:25:14 +0000

We first met Mark Franken in 2016 at a Xojo Developer Conference in Houston, Texas. Today, Mark splits his time between writing software and caring for 40 acres of rainforest. But before he traded city life for the wild, he spent decades in film and television post-production. In 2003, while still working in post, he founded Sounds In Sync, a company born out of his desire to solve the problems he faced in the editing room. What started as a side project quickly grew in popularity, and eventually, Mark shifted his focus full-time to software development. As a sound editor, Mark worked on some iconic and award-winning films including The Lord of the Rings: Return of the King, Mad Max: Fury Road, The Great Gatsby, Happy Feet Two, and Peter Rabbit.

Mac, Windows or Linux?

Develop on Mac, build for Mac & Windows

How would you explain your most recent project to a new developer?

I’ve been working on a major update for my app EdiCue, scheduled for release as EdiCue v5 in June 2025.

EdiCue is a tool used by sound editors to “cue” dialogue that needs to be re-recorded in film and TV projects. Typically, this involves working alongside the sound editing application Pro Tools to place clips on the timeline, each clip aligned with a section of dialogue and named with the exact text the actor needs to re-perform (e.g., due to background noise, unclear delivery, or script changes).

For this release, I wanted to streamline the manual cueing process by integrating AI-based speech-to-text. Specifically, I’ve added a new feature that allows users to load a WAV file, transcribe the dialogue using Whisper AI, and then export a Pro Tools session with timeline clips automatically named using the transcribed text and timing.

The integration required wrapping whisper.cpp for use in my Xojo-based application. I worked with Christian from Monkeybread Software (MBS) to build a custom plugin that bridges between Xojo and the compiled Whisper Dylib/DLL files, enabling support for macOS and Windows.

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

The biggest surprise for me has been how far AI has come in understanding, writing, and explaining code. While it still makes mistakes and doesn’t always produce perfect output, for me it’s now an invaluable tool, working in languages I hadn’t formally learned like Python and C/C++.

Thanks to AI, I’ve been able to build and compile C/C++ libraries and create my own shared libraries (Dylibs/DLLs). This has let me expose C++ functionality through clean C-style APIs, making them accessible from within my Xojo applications. It’s dramatically expanded what my apps are capable of.

In the past, I’d reach out to Christian at Monkeybread Software to write me a plugin or port specific code to Xojo, something I’ve always appreciated. But for my latest project, I needed to navigate this myself as I wasn’t exactly sure what was required from the start.

With AI’s help, I’ve successfully compiled third-party libraries that use gRPC for both macOS and Windows, built a shared library layer, and exposed the functions I needed to call from Xojo.

I learnt a lot in the process, and now I’m confident in rebuilding and maintaining these libraries as updates are released.

Xojo isn’t the only tool in your kit. What is a piece of software more people should know about?

One tool I highly recommend is Hex Fiend – a hex editor for macOS. I found it especially invaluable while updating my Xojo WAV file classes, where I needed to ensure that I was reading and writing metadata correctly.

Hex Fiend’s main window displays the raw hex data of the file, while a side panel interprets the data for various file formats, including support for WAV files. It decodes the fields, letting you see exactly how your code is affecting the underlying binary layout.

This allowed me to track down a number of bugs in my metadata handling code which would have been hard to track down otherwise.

How did you find Xojo? And when did you start using Xojo?

I first discovered Xojo back in 2002, when it was still known as RealBasic. At the time, I was working as a sound editor on The Lord of the Rings – The Two Towers in New Zealand. A fellow editor visiting from San Francisco introduced me to it, and I was immediately impressed.

I had been using Delphi/Kylix up to that point, but I was looking for a way to build cross-platform desktop apps for Mac and Windows. RealBasic’s ability to generate native applications for both platforms from a single codebase had me sold, and it fit perfectly with the kind of tools I wanted to create for audio post-production workflows.

What did you first build with Xojo? And when was that?

In December 2003, I built my first Xojo app ‘EdiTrace Auto’ for both Mac (OS9) and Windows. It was designed to load EDL (Edit Decision List) files generated by my online comparison tool at EdiTrace.com.

The app would parse the EDL events and convert them into keystroke commands that it could send to Pro Tools, automating the process of recutting sound edits to match the latest picture version delivered by the video editors. This saved sound editors a huge amount of time by eliminating the need to manually conform their sessions to match the new picture cut.

What do you build with it now?

My original app ‘EdiTrace Auto’ eventually evolved into a more powerful tool: EdiLoad. In January 2025, I released EdiLoad v6, which includes a major new feature: the ability to compare the waveforms of “assembled” WAV files against a guide track provided by the picture department.

This lets sound editors verify that WAV files recorded on set are assembling perfectly in-phase, down to the sample, with the guide audio, ensuring audio alignment is sample-accurate.

To implement this, I explored how Fast Fourier Transform (FFT) can be used to analyze the frequency content of complex waveforms. A helpful introduction for me was this YouTube video, which explained the core concepts.

After a fair amount of experimentation, I landed on a solution using an FFT function from an MBS plugin. I transform the two waveforms, sum them, and invert the result to obtain the sample-level offset.

In EdiLoad this processing is handled by a Xojo Worker, which was the first time I had used one. It was a great fit, as each alignment task just required two file paths, a time range, and a handful of user settings. The workers allow the app to access multiple cores while batch-processing all files in the assembly. You can see the feature in action in this EdiLoad v6 demo video.

What is something you worked on that you want to talk about?

One project I’m particularly proud of is writing a set of Xojo classes to read and write Pro Tools session (.ptx) files, despite having no formal software development training.

Pro Tools sessions store their data in a proprietary binary format, and there’s no public specification available. But to deliver key features my clients needed, I had to find a way to read and write these files directly from my Xojo apps.

To reverse-engineer the format, I built several test apps to see how the data was structured, and then modify known parts of the PTX files and compared results. By selectively changing binary data, I was able to track down how specific values were stored. It was a painstaking, months-long process, but it ultimately gave me the tools to read and write session data reliably.

These classes are now in used in three of my desktop apps. I also created a REST API that several online services use to convert marker data into PTX session files, allowing users to generate markers that can be imported directly into Pro Tools.

Do you earn a living with Xojo?

Yes. Xojo, and the supportive Xojo community gave me the opportunity to learn software development in my spare time while I was still working full-time as a sound editor. Over time, I was able to release my own apps through my website, gradually building up a sustainable software business.

After 20 years in post-production, I was able to transition full-time into software development. That shift also gave my family and me the freedom to leave the city (Sydney, Australia) and move to a quieter life in the bush, about six hours up the coast.

Now I work from home, doing what I love, and I’m incredibly grateful for the flexibility it gives me to be present while our kids grow up. It’s not just a career change, it’s been a lifestyle upgrade.

Do you use it for any hobbies?

Not really. When I’m not working, I try to step away from the screen. I spend my downtime in the garden, the bush, or looking after my bees. But I find quite often that I get my best code insights and ideas while I’m in nature.

What’s your biggest Xojo success?

Without a doubt, it’s been getting my applications established across the global film and TV industry, and using my background in sound editing to develop cutting-edge tools that directly support my peers.

The highlight has been receiving not one, but two Engineering Emmy Awards, one for EdiCue and another for EdiLoad. These awards recognized the impact of my apps in setting new standards for technological excellence in television post-production.

Thank you to Mark Franken for answering questions and sharing his Xojo experience with the community. Learn more about Sounds In Sync.

If you have an app, a project or a person you want to see featured in Spotlight On, tell us about it!

How To Create a Custom Button Control in Xojo – Part 3: Make Your Controls Inspector-Friendly

Gabriel Ludosanu — Wed, 28 May 2025 17:54:20 +0000

In Part 1, we built a custom button control in Xojo by subclassing DesktopCanvas. In Part 2, we enhanced it with customizable colors, corner radius, and a disabled state.

Now, let’s make the CanvasButton control even easier to use in the Xojo IDE by leveraging the Inspector Behavior feature. This allows you (and anyone using your control) to configure its appearance and behavior at design time, right in the Properties panel.

Why Inspector Behavior Matters

When you create a custom control, its custom properties will not appear in the Inspector by default. Inspector Behavior lets you choose which properties are shown and how they’re grouped. This makes your control feel polished and professional, and saves users from digging into code to tweak settings.

Step 1: Open Inspector Behavior

To customize Inspector options for your CanvasButton:

In the Xojo IDE, select the CanvasButton class in the Project Navigator.
Right-click it and choose Inspector Behavior…

Step 2: Expose and Organize Properties

In the Inspector Behavior dialog, you’ll see a list of all public properties (inherited and custom).

Make the following properties visible:
- ButtonText
- CornerRadius
- BackgroundColor, HoverColor, HighlightColor, BorderColor, TextColor (all grouped under a custom “Button Colors” section)
Organize properties into logical groups for clarity.

Tip: Defining default values for your properties in the class code means they will be automatically populated in Inspector Behavior. However, Xojo gives you even more flexibility. You can override these default values directly in the Inspector Behavior dialog, so you have full control over what new instances of your control will look like by default.

Step 3: Enjoy Design-Time Customization

With Inspector Behavior set up, you (or other developers) can now:

Change the button text right in the Properties panel.
Pick custom colors for normal, hover, pressed, border, and text states using the color picker.
Adjust the corner radius visually.

Step 4: Best Practices and Tips

Use clear group names (like “Button Colors”) to help users find related properties.
Set sensible defaults for all properties in your code, but remember you can override them in Inspector Behavior.

Conclusion

With Inspector Behavior, your custom controls feel like first-class citizens in Xojo. You and others can now design beautiful, custom buttons by simply dragging, dropping, and tweaking settings in the Inspector. No code required!

Stay tuned for future parts where we’ll explore even more advanced features.

More in this series:

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!

How To Create a Custom Button Control in Xojo – Part 2

Gabriel Ludosanu — Wed, 14 May 2025 15:00:00 +0000

In the first part of this tutorial, we built a basic custom button control using the DesktopCanvas class, giving it a custom appearance and handling the basic mouse events to provide visual feedback and raise a Pressed event when clicked.

In this second part, we will enhance our CanvasButton by adding more customization with new properties to:

set the button’s colors for different states (default, hovered, pressed)
adjust the corner radius of the button
implement a disabled state

Let’s get started!

Adding New Properties for Customization

We need to add several properties to our CanvasButton class to store the custom colors for different states, the border color, the text color, the corner radius, and the enabled state.

In the Project Navigator, select your CanvasButton class.
Go to Insert > Property (or right-click the class and select Add to “CanvasButton” > Property).
Add the following properties with the specified names, types, and default values:
- Name: BackgroundColor Type: Color Default Value: &c5e2d8b
- Name: HoverColor Type: Color Default Value: &c729fcf
- Name: HighlightColor Type: Color Default Value: &c628eff
- Name: BorderColor Type: Color Default Value: &c525252
- Name: TextColor Type: Color Default Value: &ceeeeee
- Name: CornerRadius Type: Integer Default Value: 4

These properties will hold the values that determine the button’s appearance and behavior.

Updating Event Handlers for the Enabled State

We need to modify the existing mouse event handlers (MouseDown, MouseEnter, MouseExit, MouseUp) to check if the button is Enabled before processing any mouse actions.

Select each of the following event handlers in the CanvasButton class and update the code as shown:

MouseDown(x As Integer, y As Integer) As Boolean

#Pragma unused x
#Pragma unused y

// Only process if the button is enabled.
If Enabled Then
  // Set internal state to indicate the button is being pressed.
  IsPressed = True
  // Refresh the control to show the pressed state visually.
  Refresh(False)
  // Return True to indicate that this event was handled.
  Return True
Else
  // If disabled, do not handle the event.
  Return False
End If

MouseEnter()

// Only process if the button is enabled.
If Enabled Then
  // Set internal state to indicate the mouse is hovering over the button.
  IsHovered = True
  // Refresh the control to show the hover state visually.
  Refresh(False)
End If

MouseExit()

// Only process if the button is enabled.
If Enabled Then
  // Set internal state to indicate the mouse is no longer hovering.
  IsHovered = False
  // Reset pressed state if mouse leaves while pressed (prevents accidental clicks).
  IsPressed = False
  // Refresh the control to revert from the hover state.
  Refresh(False)
End If

MouseUp(x As Integer, y As Integer) As Boolean

#Pragma unused x
#Pragma unused y

// Only process if the button is enabled.
If Enabled Then
  // Check if the button was pressed down AND the mouse is still hovering over it.
  If IsPressed And IsHovered Then
    // If true, the button was successfully clicked. Raise the custom Pressed event.
    RaiseEvent Pressed
  End If
  // Reset the pressed state regardless of whether the click was successful.
  IsPressed = False
  // Refresh the control to revert from the pressed state.
  Refresh(False)
End If

In these updated event handlers, we added an If Enabled Then check at the beginning. If the button is not enabled, the code inside the If block is skipped, preventing the button from reacting to mouse interactions. We also added #Pragma unused to the parameters x and y in MouseDown and MouseUp as they are not used in the code, which helps avoid compiler warnings. In MouseExit, we added IsPressed = False to ensure the pressed state is reset if the mouse leaves the button while the mouse button is held down.

Updating the Paint Event for Enhanced Appearance

The most significant changes will be in the Paint event where we will use the new properties to draw the button based on its current state (enabled/disabled, hovered, and pressed).

Select the Paint(g As Graphics, areas() As Rect) event handler and replace its content with the following code:

#Pragma unused areas

// Use the custom CornerRadius property.
Var currentCornerRadius As Integer = CornerRadius

// Declare variables for the colors used in drawing.
Var currentBgColor As Color
Var currentBorderColor As Color
Var currentTextColor As Color

// Determine colors based on the button's current state (enabled, pressed, hovered).
If Enabled Then
  If IsPressed Then
    // Use highlight color if pressed.
    currentBgColor = HighlightColor
    currentBorderColor = BorderColor
    currentTextColor = TextColor
  ElseIf IsHovered Then // Check for hover only if not pressed
    // Use hover color if hovered.
    currentBgColor = HoverColor
    currentBorderColor = BorderColor
    currentTextColor = TextColor
  Else
    // Use the custom background color for the default state.
    currentBgColor = BackgroundColor
    currentBorderColor = BorderColor
    currentTextColor = TextColor
  End If
Else
  // Use appropriate system or standard gray colors for the disabled state.
  currentBgColor = Color.LightGray
  currentBorderColor = Color.Gray
  currentTextColor = Color.DisabledTextColor // Use system disabled text color
End If

// Set the drawing color and draw the background shape with rounded corners.
g.DrawingColor = currentBgColor
g.FillRoundRectangle(0, 0, g.Width, g.Height, currentCornerRadius, currentCornerRadius)

// Set the drawing color and pen size for the border.
g.DrawingColor = currentBorderColor
g.PenSize = 2
// Draw the border shape just inside the background rectangle.
g.DrawRoundRectangle(1, 1, g.Width-2, g.Height-2, currentCornerRadius, currentCornerRadius)

// Enable anti-aliasing for smoother text rendering.
g.AntiAliasMode = Graphics.AntiAliasModes.HighQuality
g.AntiAliased = True
// Calculate the width and height of the button text.
Var tw As Double = g.TextWidth(ButtonText)
Var th As Double = g.TextHeight
// Calculate the X position to center the text horizontally.
Var tx As Double = (g.Width - tw) / 2
// Calculate the Y position to center the text vertically, with a small adjustment.
Var ty As Double = (g.Height + th) / 2 - 3
// Set the drawing color for the text.
g.DrawingColor = currentTextColor
// Draw the button text at the calculated centered position.
g.DrawText(ButtonText, tx, ty)

Let’s break down the changes in the Paint event:

We now use the CornerRadius property instead of a static constant for drawing the rounded rectangles.
We introduced an If Enabled Then ... Else block.
Inside the If Enabled Then block, we have a nested If IsPressed Then ... ElseIf IsHovered Then ... Else structure. This determines the currentBgColor:
- If IsPressed is True, currentBgColor is set to HighlightColor.
- If IsPressed is False but IsHovered is True, currentBgColor is set to HoverColor.
- If neither IsPressed nor IsHovered is True, currentBgColor is set to BackgroundColor.
- The currentBorderColor and currentTextColor are set directly from the BorderColor and TextColor properties when the button is enabled.
Inside the Else block (when Enabled is False), we set the colors to standard gray values (Color.LightGray for background, Color.Gray for border, and Color.DisabledTextColor for text) to give the button a disabled appearance.
Finally, the drawing commands use these currentBgColor, currentBorderColor, currentTextColor, and currentCornerRadius variables.

Using the Enhanced Custom Control

Now that our CanvasButton has more customization options and supports a disabled state, let’s see how to use these features.

If you don’t already have an instance, drag the CanvasButton class from the Project Navigator onto a window in the Layout Editor.
You can now access and set the new properties programmatically. For example, in a button’s Opening event, you could add code like this:

// Customize colors
Me.BackgroundColor = Color.RGB(200, 50, 50) // A shade of red
Me.HoverColor = Color.RGB(255, 100, 100) // A lighter red for hover
Me.HighlightColor = Color.RGB(150, 0, 0) // A darker red for pressed
Me.BorderColor = Color.Black
Me.TextColor = Color.White

// Adjust corner radius
Me.CornerRadius = 10

You can experiment with different values to see how they affect the button’s appearance. To test the disabled state, you can set the Enabled property to False.

Conclusion

We’ve now taken our custom button to the next level by adding extensive color customization, adjustable corners, and a disabled state.

This project can be downloaded from GitHub at: https://github.com/xolabsro/CanvasButton

Hope you enjoyed making the button your own! While it’s much more flexible now, there might be other features we could add down the road, so stay tuned!

More in this series:

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!

How To Create a Custom Button Control in Xojo

Gabriel Ludosanu — Fri, 02 May 2025 14:00:00 +0000

This tutorial demonstrates how to create a custom button control in Xojo using the DesktopCanvas class. It covers defining properties, handling mouse events for visual feedback, and drawing the control in the Paint event.

You can read more about DesktopCanvas in the Xojo Docs.

Let’s begin!

Add a Custom Class:

In the Project Navigator, add a new Class.
Name it CanvasButton.
Set its Super class to DesktopCanvas.

Add Properties:

ButtonText As String (Set Scope to Public, Default Value to "Click Me". To make this property visible in the Inspector, right-click the CanvasButton class in the Project Navigator, select ‘Inspector Behaviour…’, scroll through the property list to find the ButtonText variable, and make sure its checkbox is checked.)
IsHovered As Boolean (Set Scope to Private, Default Value to False)
IsPressed As Boolean (Set Scope to Private, Default Value to False)

Define `Pressed` Custom Event:

Go to Insert > Event Definition.
Name the event Pressed. This is the event that will be raised when the button is clicked.

Add Event Handlers:

Select the CanvasButton class in the Project Navigator.
Go to Insert > Event Handler. Add the following event handlers and paste the corresponding code into each:

MouseDown(x As Integer, y As Integer)

// Set internal state to indicate the button is being pressed.
IsPressed = True
// Refresh the control to show the pressed state visually.
Me.Refresh(False)
// Return True to indicate that this event was handled.
Return True

MouseEnter

// Set internal state to indicate the mouse is hovering over the button.
IsHovered = True
// Refresh the control to show the hover state visually.
Me.Refresh(False)

MouseExit

// Set internal state to indicate the mouse is no longer hovering.
IsHovered = False
// Refresh the control to revert from the hover state.
Me.Refresh(False)

MouseUp(x As Integer, y As Integer)

// Check if the button was pressed down AND the mouse is still hovering over it.
If IsPressed And IsHovered Then
   // If true, the button was successfully clicked. Raise the custom Pressed event.
  RaiseEvent Pressed
End If
// Reset the pressed state regardless of whether the click was successful.
IsPressed = False
// Refresh the control to revert from the pressed state.
Me.Refresh(False)

Paint(g As Graphics, areas() As Rect)

// Corner radius of the button shape.
Static CornerRadius As Integer = 4

 // Declare variables for the colors used in drawing.
Var bgColor As Color
Var borderColor As Color = Color.DarkBevelColor
Var TextColor As Color = Color.LightTingeColor

 // Determine the background color based on the button's current state (pressed or hovered).
If IsPressed Or IsHovered Then
  // Use a highlight color if pressed or hovered.
  bgColor = Color.HighlightColor
Else
  // Use the accent theme color for the default state.
  bgColor = Color.AccentThemeColor
End If

// Set the drawing color and draw the background shape with rounded corners.
g.DrawingColor = bgColor
g.FillRoundRectangle(0, 0, g.Width, g.Height, CornerRadius, CornerRadius)

// Set the drawing color and pen size for the border.
g.DrawingColor = borderColor
g.PenSize = 2
// Draw the border shape just inside the background rectangle.
g.DrawRoundRectangle(1, 1, g.Width-2, g.Height-2, CornerRadius, CornerRadius)

// Enable anti-aliasing for smoother text rendering.
g.AntiAliasMode = Graphics.AntiAliasModes.HighQuality
g.AntiAliased = True
// Calculate the width and height of the button text.
Var tw As Double = g.TextWidth(ButtonText)
Var th As Double = g.TextHeight
// Calculate the X position to center the text horizontally.
Var tx As Double = (g.Width - tw) / 2
 // Calculate the Y position to center the text vertically, with a small adjustment.
Var ty As Double = (g.Height + th) / 2 - 3
// Set the drawing color for the text.
g.DrawingColor = TextColor
// Draw the button text at the calculated centered position.
g.DrawText(ButtonText, tx, ty)

Use the Custom Control:

Open Window1.
Drag the CanvasButton class from the Project Navigator onto the window.

Handle the Click Event:

Double-click the CanvasButton instance on the window layout.
Add the custom Pressed event handler.
Add code inside this handler: MessageBox("Custom Button Clicked!").

Run the Project:

Run the project. Test the button by hovering, pressing, and clicking to see the visual feedback and trigger the Pressed event.

And just like that, you’ve built your own custom button! Hope you had fun following along. Keep an eye out for our next tutorials, where we’ll take this button and give it some awesome upgrades!

This project can be downloaded from GitHub at: https://github.com/xolabsro/CanvasButton

More in this series:

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!

Writing Drawing Code for Android, Desktop, iOS and Web

Geoff Perlman — Mon, 21 Apr 2025 19:28:10 +0000

When writing code it’s always a good idea to be thinking about the future. Today you are creating a desktop project but tomorrow you might need to create an Android or iOS project. That code you’re writing might be code you could use for another project for another platform.

For the most part, writing drawing code will just work because you use Xojo’s Graphics class for Android, Desktop and iOS projects. Web projects, however, don’t use the Graphics class. The WebCanvas control’s Paint event is passed a WebGraphics object. While the Graphics and WebGraphics classes have a lot in common, sharing many of the same methods with the same parameters, they are two distinctly different classes from the perspective of the Xojo compiler. That means that while the code you write will look almost identical, you still have to use a Graphics object for Android, Desktop and iOS projects and a WebGraphics object for Web projects.

Your instinct might be to simply write the code for one and then copy it to the other projects, changing Graphics to WebGraphics for Web projects. This will of course work, but then you have to remember to do this copy/paste/change operation every time you update your code. That’s not ideal.

Graphics vs. WebGraphics

With Xojo, the code can be written in such a way as to automatically handle the difference between Graphics/WebGraphics. Most often your graphics methods will be called from something that provides a Graphics or WebGraphics object for you to draw into such as a Canvas control’s Paint event. From there your code will call your methods that do the drawing. The problem is that your methods can’t use a Graphics or a WebGraphics type as a parameter because Graphics is not going to work for your Web projects and WebGraphics doesn’t exist in any framework except the Web framework. Thus using it anywhere else will result in a compiler error.

Using a Variant

Getting around this limitation is, fortunately, quite easy. Instead of using Graphics or WebGraphics as a parameter type, you use Variant. A Variant can hold any type of data from Strings to Integers, to Graphics to WebGraphics and more.

Once your drawing method gets the Variant though, it can’t use it to draw. It can only use a Graphics or WebGraphics objects. The trick is to then copy it into a Graphics or WebGraphics class variable:

Var g As Graphics = context

Var g As WebGraphics = context

The problem you now face, as mentioned earlier, is that WebGraphics only exists in Web projects. That means you have to write your code in such a way that you will declare the variable g as a Graphics object in Android, Desktop and iOS projects and as a WebGraphics object in Web projects. This can be achieved via conditional compilation. This is a simple technique that tells the Xojo compiler to only compile code into your app if conditions you specify are met. In this case, if you’re targeting Desktop or Mobile, it should compile in the line that uses the Graphics type, and if you are targeting a Web app, the line that uses WebGraphics. To conditionally compile, you just need to add that conditional code around these two lines:

#If TargetDesktop Or TargetMobile Then
   Var g As Graphics = context
#EndIf

#If TargetWeb Then
   Var g As WebGraphics = context
#EndIf

Since a project must be only one of the above types, when you run or build your project, the appropriate line of code will be compiled in. From there, you now have a variable (g) of the right type can use this to draw whatever you like. For example, there are four identical example projects (one for each project type) that show off this technique. They can be found in the Xojo IDE by choosing File > New Project, clicking on Examples, choosing the Graphics folder in the list and then the Cross-Platform Drawing folder. The examples all draw a checkerboard that looks like this:

They all contain the an identical Checkerboard class that handles the drawing. This class has DrawBorder and DrawCheckers methods that both take a Variant as a parameter. In each project is a Canvas control whose Paint event calls these methods:

Var cb As New Checkerboard
cb.DrawBoard(g)
cb.DrawCheckers(g)

The full DrawBoard method looks like this:

#If TargetDesktop Or TargetMobile Then
  Var g As Graphics = context
#EndIf

#If TargetWeb Then
  Var g As WebGraphics = context
#EndIf 

Var boxSize As Integer = Min(g.Width/8, g.Height/8) 'The size of the box
'Draw the rows
For y As Integer = 0 To 7
  For x As Integer = 0 To 7
    'Switch colors for each box in the row
    If g.DrawingColor = Color.Black Then
      g.DrawingColor = Color.White
    Else
      g.DrawingColor = Color.Black
    End If
    'Draw a box
    g.FillRectangle(x * boxSize, y * boxSize, boxSize, boxSize)
  Next
  'Switch colors again for the beginning of the next row
  If g.DrawingColor = Color.Black Then
    g.DrawingColor = Color.White
  Else
    g.DrawingColor = Color.Black
  End If
Next

In the example projects, check out the DrawCheckers method as well. It uses the same technique. What is great about this is that this class can be copied into any Android, Desktop, iOS or Web project and it will indeed just work.

Checking Out the Examples

There are four example projects (one for each project type – Android, Desktop, iOS and Web) that demonstrate the technique explained here. You can find them in the Xojo IDE by choosing File > New Project, clicking on Examples, choosing the Graphics folder in the list and then the Cross-Platform Drawing folder.

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.

Year of Code 2025: April Project, User Interface

Gabriel Ludosanu — Tue, 08 Apr 2025 15:30:00 +0000

April’s Year of Code theme is all about a great User Interface, I decided to focus on refining the user experience of an existing application. My project involves a user interface revamp of the familiar built-in ToDo desktop app example provided with Xojo.

The goal wasn’t to add new features but to explore how applying thoughtful UI design principles can significantly enhance the look and feel of an application, making it more visually appealing and cohesive.

Here are some of the key aspects of the UI revamp:

Design System Foundation: I started by establishing a basic design system. This involved defining core visual elements to ensure consistency across the entire application interface.
Typography Definition: Specific styles were defined for how titles and standard text should appear. This helps create a clear visual hierarchy and improves readability.
Consistent Color Palette: A specific set of colors (Light & Dark mode) was chosen and implemented throughout the project, contributing to a unified and more polished look.
Refined ListBox Appearance: The standard DesktopListBox control received some visual tweaks to better align with the overall updated aesthetic.

The aim was to demonstrate how focusing on UI details can elevate even a simple example application.

Here’s a glimpse of the revamped ToDo app:

You can find the complete source code for this UI-enhanced ToDo app project on GitHub.

Stay tuned for more exciting projects as we continue our Year of Code 2025 journey!

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!

Year of Code Project

How to Play:

The Prizes:

Property List Editor, Integrated in the IDE

Javier Menendez — Tue, 25 Mar 2025 15:34:12 +0000

Starting with Xojo 2025r1, a new Property List Editor is available for both Desktop (macOS) and iOS projects under Build Settings > macOS and Build Settings > iOS. This editor simplifies the process of adding custom entries that your app may require, beyond those automatically included by Xojo.

Some projects require additional entries in the generated Info.plist file. Previously, the only way to include these entries was to create the file manually using an external text editor, then drag and drop it into the project’s Navigation area. This allowed its contents to be merged with the entries automatically generated by Xojo in the final Info.plist file within the app bundle.

Now, the Property List Editor in the Xojo IDE provides a simpler way to add these entries. Once added, you can even export the contents to an external file, making it easy to reload them later for other projects that require the same set of entries. This saves time by eliminating the need to manually re-enter them.

What about projects that already reference an external Info.plist file? No worries—Xojo will automatically merge its contents with the entries added via the Property List Editor. If the same key exists in both the external file and the Property List Editor, the value from the Property List Editor will take precedence, overriding the one in the external file.

As for the types of data that can be added to the Property List Editor, the expected options are offered:

For collections:

Dictionary
Array

For primitive values:

Number
String
Boolean

For primitive value entries, the Editor allows you to convert them to any of the other two supported primitive types. For example, if you add a Number entry, you can later select it and convert it to a String or Boolean type as needed.

Of course, the entries added through the Property List Editor are applied and saved to the project file in addition to any changes made using the Property List Editor. The next time you open the project in Xojo, you’ll find the previously applied Info.plist entries already in place.

Tip: If you’re using the new Publish feature to send your macOS apps to App Store Connect, you can simplify Apple’s encryption compliance process by adding a new Boolean entry in the Property List Editor with the following values:

Key: ITSAppUsesNonExemptEncryption
Value: False

By doing this, you won’t need to manually go through the “Manage” option for Apple’s encryption compliance on the App Store Connect website—provided your app does not actually use encryption that requires disclosure.

In Summary

Whether you’re developing macOS or iOS projects, the integration of the Property List Editor in the Xojo IDE streamlines the process of managing additional Info.plist entries. You no longer need to manually create and import external files —now, you can add, edit, and reuse entries directly within the IDE. This not only saves time but also ensures consistency across multiple projects!