Am I affected? What do I do?

If you only read one section, read this one.

• On Xojo Cloud (Web 1 or Web 2)? You’re covered. Nothing to do.
• Using Lifeboat? Update Lifeboat and redeploy.
• Self-hosted behind Apache or Nginx? Drop in the filtering rule below. If you’re on Web 2, also upgrade to 2026r1.2 if possible.
• Self-hosted with the Xojo app exposed directly? On Web 2, upgrade to 2026r1.2 if possible, otherwise put a reverse proxy in front. On Web 1, put a reverse proxy in front (which is what we’d recommend either way).

The full details follow.

Timeline

• Thursday, the 23rd. A public issue and a private message landed on the same day, both pointing at the same bug.
• Thursday through Monday. We tracked down the root cause, wrote the fix, and tested it.
• Tuesday, the 28th. 2026r1.2 shipped with the patch.
• Wednesday, the 29th. Xojo Cloud patched at the platform level.

Under a week from the report to a patched release, with the platform-level mitigation following the next day.

What Happened

A request with a malformed percent-encoded sequence in a query parameter could crash a running Xojo Web app. The smallest reproducer is something like ?x=%. That’s a % not followed by two hex digits, which is invalid percent-encoding and isn’t decodable.

The bug lives in DecodeURLComponent. When the method ran into invalid input, it raised an exception instead of handling the input gracefully. Because the framework calls this method while parsing incoming requests, anyone could crash a web app by sending a single malformed URL. No authentication, no special headers, no payload. Just a bad query string.

A few things worth being upfront about:

• The bug has probably been there since DecodeURLComponent was introduced. Every Xojo release that ships the method might be affected.
• Both Web 1 and Web 2 are known to be affected. The Web framework has been calling this method on incoming requests across both generations.
• It’s not just a Web problem. DecodeURLComponent is a general-purpose method, and the same crash can happen in Desktop and other project types if you call it on attacker-controlled input. Web is the obvious target because requests arrive from the network, but the underlying issue isn’t Web-specific.

The Fix

In 2026r1.2, DecodeURLComponent no longer crashes on invalid input. Instead, it returns an empty String when the input contains a malformed percent-encoded sequence.

We thought about a few approaches and went with this one on purpose, for being consistent with the other sanity checks we do on this method. An empty return value lets existing code keep running rather than letting an exception bubble up through request handling, which is what you want from a method that’s frequently called on untrusted input. If your code already wraps DecodeURLComponent with its own validation, the new behavior gives you a clean signal to act on (an empty result) instead of an exception to catch.

Xojo 2026r1.2 is the only release with the fix. Web 1 won’t be getting a backported patch. What that means in practice is covered below.

What Xojo has already done for you

Xojo Cloud has been patched at the platform level. As of Wednesday 29th, Xojo Cloud rejects requests with malformed percent-encoding before they ever reach your app, returning a 400 Bad Request from the front-end web server. This protection doesn’t care which Xojo version your app was built with, and it covers Web 1 and Web 2 the same way.

If your app runs on Xojo Cloud, you don’t need to redeploy, upgrade, or change anything. We rolled this out specifically so that users who can’t upgrade right away are covered, including Web 1 users who can’t upgrade to a fixed version at all.

What you should do

The right move depends on which Web version you’re on and where your app runs.

If you’re on Web 2

Upgrade to 2026r1.2 and redeploy if you can. That’s the cleanest fix and it addresses the issue at the source.

We know “just upgrade” isn’t always realistic. You might be on an older version because your license has expired, because a third-party plugin you rely on hasn’t caught up yet, because a newer Xojo release introduced a regression you can’t ship around, or for any number of other reasons. If that’s you, the hosting-based mitigations below will protect your app in the meantime, and they work regardless of which Xojo version you built with.

If you’re on Web 1

There’s no Xojo release that patches DecodeURLComponent for Web 1, so the fix has to live outside your app. The good news is that if you follow Xojo’s standard hosting recommendations, you’re fully covered against this specific issue:

• Stay on Xojo Cloud. You’re already protected.
• Use Lifeboat. Tim Parnell shipped a Lifeboat update that catches malformed percent-encoding before it reaches your app. Update Lifeboat and redeploy.
• Run behind Apache or Nginx with the rules in the next section.

Separately, and on a longer horizon: Web 1 isn’t receiving framework patches anymore in general, so if you’re still on it, this is a reasonable moment to start thinking about a migration to Web 2. That’s a much bigger conversation than this post, but worth flagging.

Hosting-level mitigations

These rules reject malformed percent-encoded URLs at the web server, before the request reaches your Xojo app at all. They work for Web 1 and Web 2, and they don’t depend on the Xojo version you built with.

Apache:

# Reject malformed percent-encoding in the URI.
RewriteCond %{THE_REQUEST} %(?![0-9A-Fa-f]{2})
RewriteRule .* - [R=400,L]

Nginx:

# Reject malformed percent-encoding in the URI.
if ($request_uri ~ "%(?![0-9A-Fa-f]{2})") {
  return 400;
}

Reload your web server after updating the config (apachectl graceful or nginx -s reload) and check that a request like https://yourapp.example.com/?x=% comes back as 400 Bad Request.

These two snippets aren’t the only way to handle this. The goal is just to block malformed URLs before they reach your app, however you do it. If you’re running mod_security, for example, a rule that rejects URIs containing invalid percent-encoding will get you the same result. Same idea for any WAF, edge filter, CDN, or load balancer in front of your stack: catch the bad request, return a 400, move on.

If your Xojo app is exposed directly to the internet

If your Web app is talking to the internet without a reverse proxy in front of it, your options are narrower. On Web 2, upgrade to 2026r1.2 if you can. On Web 1, or on Web 2 if upgrading isn’t an option, you’ll need to put Apache, Nginx, or Lifeboat in front of your app, or move to Xojo Cloud, our managed hosting solution.

This is also a good moment to revisit the setup more broadly. Xojo recommends always serving Web apps behind a web server, both for performance and as a defense-in-depth measure against bugs like this one. A reverse proxy would have neutralized this specific issue before it reached the framework, and it’ll do the same for the next class of issue too.

If you use DecodeURLComponent in a non-Web project

The crash isn’t unique to Web. If you’re calling DecodeURLComponent on input you don’t control (anything coming from a user, a file, a network response, a clipboard), the same bug can hit a Desktop, Console, or other project type.

Upgrade to 2026r1.2 if you can; that’s the proper fix.

If you can’t upgrade, you’ll need to sanitize the input yourself before calling DecodeURLComponent. The check is simple in principle: every % in the string must be followed by exactly two hexadecimal characters (0-9, A-F, a-f). If any % doesn’t meet that condition, treat the input as invalid and don’t pass it to DecodeURLComponent. A small helper that validates the string up front and either returns early or substitutes an empty value will keep your app from crashing on the same kind of malformed input that triggers the Web bug.

Acknowledgments

Thanks to the user who reported this through both public and private channels. That’s exactly the kind of disclosure that lets us turn a fix around in under a week. Thanks also to Tim Parnell for the fast Lifeboat update, which gave self-hosted users a drop-in mitigation almost immediately.

If you find a security issue in Xojo, please report it privately. You can email support@xojo.com or file a confidential issue on the issue tracker. Both reach us, and either one lets us get a fix out before the details become public, protecting the rest of the users.

References

• Release notes for 2026r1.2

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

New Controls

Three new controls have been added to the Web framework in this release, aiming to close the difference gap between Web and the other project types.

WebSwitch is a toggle control that mobile developers will already be familiar with. It’s been available on iOS and Android for a while. It’s now available for web projects too, so if you’ve been approximating a toggle switch using a styled checkbox, you can finally retire that workaround.

WebColorPicker brings color selection to web apps in the same way DesktopColorPicker does for desktop. Drop it in from the Library, wire up the event and you have a color picker the Xojo way.

This is how WebColorPicker looks like in your browser:

The third new control adds barcode reading support. Your web app can now read barcodes directly from the user’s camera, from desktop or mobile browsers. This opens up a lot of practical use cases: Inventory systems, ticketing, product lookups, that previously would have pushed you toward a native mobile app.

Again, drop the Barcode control into your project and implement the events:

That’s it! Your web apps can scan a great variety of barcodes now. Including QR, Data Matrix, Aztec, PDF 417 and much more!

Icons on WebButtons

WebButton now has an Icon property. You can assign any WebPicture to it, or use one of the Bootstrap icons that are already bundled with the framework. It’s a small addition, but it makes a noticeable difference when building action-heavy interfaces where a label alone doesn’t communicate enough at a glance.

Add a button into your project:

Configure its Icon property in the Opening event:

Me.Icon = WebPicture.BootstrapIcon("key-fill")

If you don’t specify a color in BootstrapIcon, it will inherit the button caption color in this case. This is the easiest way to support Dark Mode with the new WebButton.Icon property, without doing any special tricks.

Here is how it looks like at runtime:

Dark Mode:

WebLabel: Semantic HTML and Proper Element Types

Two related changes landed for WebLabel in this release. The first is a correctness fix: the control was previously rendered using the HTML <label> element, which is semantically meant to label form inputs, not to display general text. That has been corrected.

The more interesting addition is that you can now choose which HTML element WebLabel renders as. If you want a label to be an <h1> or an <h2>, you can set that directly in the Inspector. This is useful not just for visual styling, but for accessibility tools and search engines that rely on page structure to understand content hierarchy.

Improving both, accessibility and making search engines happier, are some of our goals for 2026. You will continue seeing improvements in this sense.

WebTextArea Gets AddText

WebTextArea now has an AddText method, consistent with how the control works on Desktop and Mobile. If you’re writing code that targets multiple platforms, this kind of parity saves you from having to check which target you’re on, before appending text.

Scale Indicator on WebMapViewer

WebMapViewer now has a HasScaleIndicator property. When enabled, a small visual scale appears on the map showing real-world distance. It makes a difference in apps where users need spatial context. Field work, logistics or anything where “how far is that?” is a question users might actually ask.

Performance and Modernization Under the Hood

A few changes in this release won’t be immediately visible, but they improve things for everyone.

Bootstrap has been updated to v5.3.8 which fixes some issues introduced in v5.3.7 impacting Xojo. The TypeScript compiler has been updated to v5.9.3, and the compilation target has been bumped from ES6 to ES2020. Unused code in the Web Framework has been cleaned up to reduce the compiled bundle size.

Xojo has also removed its own internal usage of Modernizr. The library is still present for now so existing apps that rely on it won’t break, but it’s no longer used by the framework itself and will be removed in a future release.

If you’ve been meaning to audit your web app for performance, this is a good moment to look at SendEventsInBatches and LazyLoadDependencies on WebSession as well. Both now default to True on new projects, so if your existing app has them disabled, it’s worth trying them out. These properties have been around for a while already but were turned off by default.

API Consistency Cleanups

A few methods have been deprecated in favour of names that are consistent with the rest of the framework:

• WebApplication.AutoQuit → AllowAutoQuit
• WebListBox.ReloadData → ReloadFromDataSource
• WebRadioGroup.RemoveAllRows → RemoveAll, and RemoveRowAt → RemoveAt

Your existing code will still compile, but it’s worth updating these when you get a chance.

Wrapping Up

Between new controls, better HTML semantics, and a leaner runtime, 2026r1 is a worthwhile update for anyone building web apps with Xojo. Check out the full release notes for the complete list of changes.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

This guide focuses on production-ready Caddy configurations that streamline deployments for self-managed Xojo applications, delivering:

• Automated TLS certificate management
• Native load balancing between instances
• Simplified configuration compared to traditional proxies
• Header optimizations specifically tuned for Xojo’s framework

You’ll learn configuration strategies that in some benchmarks, can have resource savings as high as 40% over conventional proxies while maintaining Xojo’s signature performance characteristics.

Core Configuration Strategies

Basic Reverse Proxy Setup

yourdomain.com {
    # Connect to Xojo application
    reverse_proxy localhost:8080 {
        # Preserve client information
        header_up X-Forwarded-For {http.request.remote.host}
        header_up Host {http.request.host}
    }
    
    # Automate HTTPS
    tls admin@yourdomain.com
}

Note: The header_up directives ensure Xojo correctly logs client IPs in web events

Load Balancing Across Instances

app.yourdomain.com {
    reverse_proxy localhost:8080 localhost:8081 localhost:8082 {
        load_balancer {
            policy round_robin
            health_interval 10s
            health_uri /health
        }
        # Timeouts for heavy processing
        lb_try_duration 30s
    }
}

Security Hardening Measures

yourdomain.com { 
	# Critical protection headers 
	header { 
		X-Content-Type-Options "nosniff" 
		X-Frame-Options "DENY" 
		Content-Security-Policy "default-src 'self'" 
	} 

	# Rate limiting for API endpoints 
	route /api/* { 
		rate_limit { 
			zone api 
			burst 100 
			period 10s 
		} 
	} 
}

Production-Ready Deployment Scripts

Linux Systemd Service
/etc/systemd/system/xojo-caddy.service:

[Unit]
Description=Xojo Caddy Reverse Proxy
After=network.target

[Service]
Type=simple
User=caddy
ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

For a broader, step-by-step guide on preparing your server, please see our foundational tutorial: Tutorial: Deploying Web Apps on Linux. The systemd service above integrates perfectly into that workflow.

Windows Deployment Package
Xojo-Caddy.bat:

@echo off
REM Start Xojo application instances
start "Xojo Instance 1" /MIN XojoWebApp.exe --port=8080
start "Xojo Instance 2" /MIN XojoWebApp.exe --port=8081

REM Launch Caddy reverse proxy
start "Caddy Proxy" /MIN caddy.exe run --config C:\caddy\Caddyfile

Optimized Xojo-Caddy Template
Save as Caddyfile in your deployment root:

# Production-Grade Xojo Proxy Template
yourdomain.com, www.yourdomain.com {
    # Automated HTTPS
    tls contact@yourdomain.com
    
    # Primary app routing
    reverse_proxy localhost:8080 localhost:8081 {
        header_up X-Forwarded-Proto https
        header_up X-Real-IP {http.request.remote}
    }
    
    # Static content handling
    handle /static/* {
        root * /var/www/static
        file_server
    }
    
    # Security headers
    header {
        Strict-Transport-Security "max-age=31536000"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
}

Conclusion

Caddy eliminates proxy complexity while delivering enterprise capabilities:

1. Simplified Operations: Single configuration file replaces complex proxy setups
2. Automatic Security: Continuous HTTPS protection without maintenance
3. Effortless Scaling: Built-in load balancing grows with your user base
4. Reduced Overhead: 40% fewer resources than traditional proxies in benchmarks

Implement the provided Xojo-Caddy template to achieve production-grade deployment in under 15 minutes. Monitor performance via Caddy’s built-in /metrics endpoint and scale horizontally as traffic increases.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

The End Result

The latest drag and drop example has a functional GUI that looks professional and feels intuitive. All without writing a single line of JavaScript (we will enhance it a bit with some CSS, though).

Please note this is a sample project created to explore drag and drop, not a full featured Kanban board. I’ll omit on purpose things like persistence. The complete project can be found in the Examples section of the IDE, under Platforms > Web.

Let’s walk through how to make it happen.

Creating the Required Components

First, we need to define the building blocks of our Kanban board. In Xojo, WebContainers are perfect for modularizing reusable UI elements. Here’s what we’ll create:

• KanbanCard
  A WebContainer to represent each task card. It’ll have a simple label for the task name (e.g., “Write blog post”) and maybe a colored border or handle to indicate it’s draggable. Add a WebLabel for the text and set its properties in the Inspector to make it visually distinct.
• KanbanCardContainer
  Another WebContainer to act as a column. It’ll hold multiple KanbanCard Containers and serve as both a drag source (where cards come from) and a drop target (where cards land). Include a WebLabel at the top for the column title (e.g., “To Do”) and a rectangular area below it to house the cards.
• Main Page
  A WebPage to host everything. This is where we’ll arrange our columns side by side.

In the Xojo IDE, drag a WebContainer onto your project for the Card, another for the Column, and set up three instances of the Column Container on the main WebPage (“To Do,” “In Progress,” “Done”).

KanbanCard

This component will be pretty easy to build. It is basically a WebRectangle with a WebLabel that we will use for the Title. To make it easier to update, I’ve added a Title Computed Property that will update the TitleLabel if needed.

For the background WebRectangle, we will use the following ColorGroup. Please notice Xojo added support for Named colors, that will rely on the current Bootstrap theme, supporting Dark Mode:

As you can see, BackgroundRectangle and TitleLabel controls are implementing the Opening event. This is just to set the mouse cursor that will be shown when we hover:

Me.Style.Cursor = WebStyle.Cursors.Move

The container itself is also implementing the Opening event. This is to make this control draggable, using the following line of code:

AllowTextDrag(WebDragItem.DragActionTypes.Move)

Any descendant of the WebUIControl class is draggable. And yes, that includes custom controls created with the Web SDK.

For the WebDragItem.DragActionTypes Enumeration, you can choose one these options:

In this case we will only be allowed to “Move” a card from one place to another.

There are cases where it makes sense to support multiple drag action types. In your operating system’s file browser, when you drag and drop files and folders, you can change between Move, Link or Copy by using Keyboard shortcut combinations. Depending on the drag action type, the element will be moved, a symbolic link will be created, or it will be copied, respectively.

Normally you will implement just Move or Copy, but keep in mind it’s possible to have more (at the cost of increasing the learning curve of your application for your users)

Allowing something to be dragged is the first of two steps. You also need a place to drop these items into.

KanbanCardContainer

This container will be more elaborate, but should be easy to follow. Let’s see how it works at runtime, with some annotations:

The WebLabel we used for the Title and the WebButton used for adding new cards are positioned manually in the IDE designer. Same as the invisible WebRectangle holding the KanbanCard items and the KanbanAddCard custom button.

But instead of placing our cards manually, we’ll take advantage of the browser’s capacity for doing this job for us. We just want to add them dynamically at runtime and let the browser stack them vertically, automatically. We also want the browser to display a scrollbar if the columns have several cards.

Here is the code we will add to the WebRectangle:

// Let the framework know we want to let the
// browser place the items automatically
Me.LayoutType = LayoutTypes.Flex

// This style will ensure cards won't be
// placed horizontally by the browser
Me.Style.Value("flex-direction") = "wrap"

// If there are more cards than available
// space, this style will allow the user
// to scroll
Me.Style.Value("overflow") = "auto"

Let’s add some methods to add and remove cards at runtime.

• AddCardWithTitle(title As String)
• AddCardWithTitleAt(title As String, index As Integer)
• RemoveCardAt

Moving Cards Between Columns

Here’s where Xojo’s drag and drop shines. Each Card Container needs to be draggable and each Column Container needs to accept dropped cards. In Xojo:

1. Make Cards Draggable: Open the KanbanListCard in the IDE and implement the Opening event. Enter this code:
   AllowTextDrag(WebDragItem.DragActionTypes.Move)
2. Accept Card Drops: Open the KanbanCardContainer and implement the Opening event. This is the code we need in order to accept drops:
   AcceptTextDrop(WebDragItem.DragActionTypes.Move)
3. Remove from Source: To move (not copy) the card, in the source Column’s DragEnd event, remove the dragged card from its original parent after a successful drop.

With this, you can drag a card from “To Do” to “In Progress,” and it’ll visually jump columns. Xojo handles the heavy lifting. No JavaScript or DOM manipulation needed!

The Hard Part: Reordering Cards

Reordering cards within a column, or dropping a card into another column in a specific position is trickier. You need to detect where the card lands among its siblings and adjust their positions. Xojo’s drag and drop doesn’t natively sort UI elements, so we’ll simulate it.

There are several ways to achieve this, let’s explore some options.

One would be to deal with X/Y coordinates. Once you drop a card, you could take a look to see where the card landed, compare the coordinates with the other cards and reorder them accordingly. In desktop and mobile projects this could be a valid solution. In web projects, dealing with specific coordinates might work, but there are more accurate and easier solutions.

The second way could be good enough in most cases. Cards could also accept drops so, if you drop one card on another, we just have to put the card being dropped in the position where it’s being dropped, and push down the rest of the stack. This way you won’t need to scratch your head and deal with screen coordinates or control dimensions. The end result will be based on this idea.

But what should we do to generate the gap between Cards? Maybe you can create a transparent Container that also accept Card drops, to simulate the gap between cards.

This would work for you, and I honestly recommend you to give it a try, it’s super easy to implement and it will just work. If you don’t want to explore the CSS rabbit hole, that’s fine, this can be your bus stop.

Two downsides:

• You won’t have animations
• You will double the amount of controls on screen (performance may suffer)

I went in another direction though. Using some CSS, you can add and modify margins on the fly, with neat transitions. In my sample project, the margin between cards is managed by the `margin-top` CSS style.

And here is where the Xojo Framework helps. To make styling easier, it adds a CSS class to the element being dragged and also to the element where the mouse is over, when it’s accepting a drop.

dragging – The HTML element being dragged will have this property
dragover – The HTML element under the other element being dragged

In this case, the “Bar” card will receive the dragging CSS class, while “Test #2” will receive the dragover CSS class, while the “Bar” car is above.

I’ve added some transparency to elements with the dragging class. As you can see in the screenshot, the “Bar” Card opacity is set to 30%.

For dragover class, I’ve added some margin and transitions. If you drag something into a card, the top margin will grow, simulating it’s making room for the card you are about to drop.

Here is how the HTML Header section of the sample project looks like. It isn’t too much code, but it does uses some somewhat advanced CSS tricks:

This approach keeps cards neatly stacked and sortable. It’s the “hard part” not because you will have to write a lot of code, but because you’ll actually have to think a solution that won’t require roundtrips between the browser and the server. Xojo’s event system makes it manageable without JavaScript, and with some CSS, the result will be great.

Some CSS Enhancements

In some cases I’m using shadows and border radius using the Bootstrap’s CSS classes.

As you can see, I’m using rounded-2 for the border radius, and shadow-sm to easily add a shadow to the cards.

You can read more about this in the following blog post:
Introducing Named Color and CSS Classes in Xojo Web

There is a related sample project you might want to check:

Closing Thoughts

This has been a fun experiment to explore the Xojo Web drag and drop feature. Give the sample project a try and explore each control to see how it’s been created. I can’t recommend enough that you try to build it from scratch (and ask in the forum if you get stuck!)

We can’t wait to hear about how you plan to introduce drag and drop into your projects. Don’t be shy and create a forum thread to show what you have built, or what you are working on.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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

Write a Xojo Plugin

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

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

Build a Xojo Plugin

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

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

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

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

Example: CubeSQLPlugin

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

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

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

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

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

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

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

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

Build for all Platforms and Architectures

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

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

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

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

macOS

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

Linux

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

Windows

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

How to Build your Xojo Plugin

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

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

How to Transition from Manual to Automated

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

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

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

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

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

A Fun Fact

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

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

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

That’s All Folks!

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

This article will show you how to automatically record queries and commands in any Xojo database class to help you debug and improve database operations by using method overriding. This will help you:

• Debug SQL operations faster by seeing exactly what’s being executed.
• Spot errors in your SQL queries or parameters before they become runtime issues.
• Gain transparency into your app’s database behavior.

By the end of this tutorial, you’ll have a clear understanding of:

• Method overriding: What it is and how you can use it to extend built-in Xojo classes.
• Subclassing database classes: Learn how to develop a custom database class with added logging functionality to improve database management and tracking.
• Logging SQL commands and parameters: Discover how to effectively capture and log database operations such as SELECT, INSERT, and DELETE to enhance visibility and improve database performance.

What is Method Overriding?

Method overriding, a fundamental concept in object-oriented programming (OOP), lets you customize how a subclass implements its superclass’s methods. In Xojo, this powerful feature allows you to enhance built-in classes without modifying their original code, ensuring you preserve core functionality while adding your own features.

How Method Overriding Works in Xojo

Let’s break it down step by step with a simple example. Imagine you’re working with the SQLiteDatabase class, and you want to modify the behavior of the ExecuteSQL method to log every SQL command executed.

1. Create a Subclass:
   • Create a new class in Xojo and set its Super to SQLiteDatabase. This means your new class inherits all the properties and methods of SQLiteDatabase.
2. Override the Method:
   • In your new subclass, define a method and from the Method Name picker, select ExecuteSQL.
   • Add your custom logic, like logging the SQL command to the Xojo debugger.
3. Call the Original Method:
   • Use the Super keyword to call the original ExecuteSQL method in the superclass. This ensures the original behavior is preserved alongside your custom logic.

Extending Xojo’s SQLiteDatabase with Method Overriding

Let’s enhance Xojo’s SQLiteDatabase class by creating a subclass that automatically logs SELECT queries and their parameters. To make this process easier, use the built-in “Full-Text Searching 5” example project, which already includes various database operations.

1. Create the MySQLiteDatabase Subclass

1. From the Insert menu, select Class.
2. Name the new class MySQLiteDatabase.
3. In the Inspector, set the Super field to SQLiteDatabase.

This tells Xojo that MySQLiteDatabase will inherit all the behavior of SQLiteDatabase, allowing you to override its methods.

2. Override the SelectSQL Method

Now, you’ll override the SelectSQL method in your MySQLiteDatabase class. This method is used for SELECT queries, so you’ll add logging to display the query and its parameters in the debugger.

Public Function SelectSQL(query As String, ParamArray values() As Variant) As RowSet
  // Log the SELECT query
  System.DebugLog("[DEBUG] SelectSQL called: " + query)
  
  // Log the parameters (if any)
  If values.LastIndex >= 0 Then
    Var stringValues() As String
    For Each v As Variant In values
      stringValues.Add(v.StringValue) // Convert Variant to String
    Next
    System.DebugLog("[DEBUG] Parameters: " + String.FromArray(stringValues, ", "))
  End If

  // Call the original SelectSQL method
  Try
    Return Super.SelectSQL(query, values)
  Catch error As DatabaseException
    // Log any errors
    System.DebugLog("[ERROR] DatabaseException: " + error.Message)
    Raise error // Re-raise the exception so the app can handle it
  End Try
End Function

3. Replace the Database Property

Now that you’ve created the MySQLiteDatabase subclass, you need to update the example project to use it.

1. Open Window1 in the Project Browser.
2. Locate the DB property in Window1. It is currently defined as DB As SQLiteDatabase:
3. Change the type of DB from SQLiteDatabase to MySQLiteDatabase. To do this:
   • Select the DB property.
   • In the Inspector, update the Type field to MySQLiteDatabase.

Additionally, under the Opening event of Window1, change DB = New SQLiteDatabase to DB = New MySQLiteDatabase.

This replaces the original SQLiteDatabase with your custom subclass, ensuring all database operations now use your overridden SelectSQL method.

4. Test the Logging

With the subclass in place, run the project and test the logging functionality.

1. Run the project.
2. Perform a search in the app’s UI. Each search generates a SELECT query using the SelectSQL method.
3. Check Xojo’s Messages Panel for output. You should see the SQL query and its parameters logged.

Example Output:

[DEBUG] SelectSQL called: SELECT highlight(ftstest, 0, '<', '>') FROM ftstest WHERE ftstest MATCH 'know' ORDER BY rank;

Additional Enhancements

Now that you’ve created a foundation for extending Xojo’s database classes by logging queries with your custom subclass, it’s time to think about how you can take this further. Below are several ideas for additional enhancements that will make your subclass more robust, versatile, and useful for debugging and performance monitoring.

Log Additional Methods

While you’ve started with the SelectSQL method, your app likely performs other database operations, such as INSERT, UPDATE, DELETE, or even transactions. You can override methods like ExecuteSQL to log these operations along with their parameters. Extending the logging functionality to these key methods ensures a complete picture of all database activity.

Additionally, logging transactional methods like BeginTransaction, CommitTransaction, and RollbackTransaction can help you trace when database changes are grouped together and ensure data integrity.

Tip: You can incorporate the Log4Xojo project.

Support for Multiple Database Classes

If your app uses different database types, such as MySQLCommunityServer or PostgreSQLDatabase, you can generalize your logging functionality to work with all of them. This can be achieved by creating a base class for logging that inherits from Database and then extending it for specific database types. This approach ensures consistency and reusability across different database systems.

Monitor Query Performance

Tracking the time it takes for queries to execute can give you valuable insights into your application’s performance. By measuring the duration of each query, you can identify slow queries and optimize them for better efficiency. Additionally, you could log a warning if a query takes longer than a specified threshold, helping you catch performance issues early.

Automatically Retry Failed Queries

Sometimes, database operations fail due to transient errors, such as network interruptions or locked tables. Implementing retry logic for failed queries can make your app more resilient. For example, you could attempt a query up to three times before logging it as a failure. This is particularly useful for apps that rely on remote database servers, where connectivity issues are more likely.

Add Context-Specific Metadata

Including additional context in your logs can make them more meaningful. For example, you might log:

• The name of the method or function that triggered the query.
• The user ID or session ID (if applicable) for tracking user-specific database activity.
• Tags or labels to group related queries or transactions.

This kind of metadata makes it easier to understand the “why” behind a query, not just the “what.”

Wrapping It All Up

Congratulations! You’ve taken a deep dive into one of the most powerful techniques in Xojo development: extending built-in classes, like SQLiteDatabase, to meet your specific needs. By following the steps in this tutorial, you’ve learned how to override methods, create a custom database subclass, and log SQL queries for better debugging and transparency.

What’s Next?

If you enjoyed this tutorial, we’d love to hear from you! Share your thoughts, your customizations, or any challenges you faced in the Xojo forums. If you’ve built something amazing using this technique, let us know—we’d love to feature your work in our community showcase.

Keep coding, keep innovating, and as always, happy developing!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Community and Resources

In order to succeed with Xojo whether you are an existing user or a new user, you need great resources. In 2024 there have been over 95 new posts on the blog. The latest addition to the Xojo team, Gabriel Ludosanu, has written some wonderful tutorials and explainers on the blog that can quickly get you up to speed with many useful Xojo features.

Speaking of Gabriel, he’s also been enhancing our YouTube channel with Shorts, which are short-form videos (in portrait-style) that quickly introduce or highlight topics.

For our many new users, the Xojo Textbook and Teacher’s Guide have been updated. In addition, we do our best to support Xojo for students, such as with the GitHub Student Developer Pack.

In the spring we made a change to Xojo Lite to allow it to use the text project file format, making it easier to share your projects using services such as GitHub. We also made Xojo for Linux available for free to better match the ethos of that platform.

We are pleased to share that 2024 was a year of tremendous growth in the Xojo community as our GitHub Student Developer Pack and changes to Xojo Lite have helped drive more new users to Xojo than we’ve seen in years!

New users help drive growth in Xojo, but its lifeblood is our dedicated user base. With four releases in 2024, we continue to improve and make Xojo better for everyone. One thing we’ve been working on for each release is ensuring there are blog posts highlighting major new features, often written by the engineer that worked on the feature.

And of course don’t forget about our long-standing resources such as the Xojo forum, YouTube channel, documentation and example projects all of which get new information through each year.

With all that said, another valuable part of the community is the Xojo MVPs. These dedicated Xojo users help us by providing design feedback, testing of new features while they are in early development and general advice. They truly do help point Xojo in the right direction!

New Features and Improvements

We introduced many shiny new features in 2024 but we also hit the bugs hard. We fixed 16% more bugs this year compared to 2023. We fixed 224% more “old” bugs (that’s bugs that are 2 or more years old) compared to 2023. Overall, we fixed over 900 bugs, closing more bugs in 2024 than were created. We have to give a special shout-out to Robin for his work with the Issues queue. He helps ensure we have reproducible projects for bugs, which makes fixing them much more realistic.

But it’s not just all bug smashing, of course. Here are some of the other great things we’ve worked on throughout 2024.

Let’s start with some things that are not actually part of a specific Xojo release. There have been several robust example projects that we’ve produced to help you use Xojo in fun and exciting new ways. Some include:

• In Using ChatGPT, Geoff shows you how to connect to the ChatGPT API.
• Log4Xojo by Gabriel adds some slick app logging features.
• Android Design Extensions by Xojo MVP Martin adds “910+ UI extensions for Xojo Android framework”.
• DBKit, although not new in 2024, has been continually improved by Geoff, our intrepid founder and CEO.

Moving on to new features, perhaps one of the biggest announcements was the addition of preemptive threads, spearheaded by William with lots of feedback and testing from Xojo MVP Kem. Preemptive threads allow Xojo apps to even more easily take advantage of the multiple CPU cores that are prevalent on today’s computers and devices, resulting in speed improvements that can be orders of magnitude better than using standard threads. William also added the highly useful ZIP capabilities, recently got XojoScript working with ARM on Windows, has improved the debugger and exposed our SSLSocket TLSv1.3 support.

Ricardo has been doing tremendous work on the web framework, making it much faster and adding new features such as Popovers, CSS classes, simplified & faster WebDataSource and Named Colors (Ricardo’s fav!). If you haven’t looked at Xojo Web in a while, you might want to take another peek.

We also did a major upgrade to Xojo Cloud’s Linux backend that kept Travis busy for a while.

Javier has led improvements in the Xojo framework and iOS, adding long-requested features such as Popovers and Barcodes/QR codes. In addition, iOS can now use the privacy manifest. Speaking of Javier, he also improved macOS app distribution with Sandboxing, Hardened Runtime and Notarization, one of your top feature requests. Charting and PDF have also continued to improve under Javier’s watchful eye.

Android has been getting lots of fixes and new features in 2024 with Paul adding such things as tablet support, localization, better Declare capabilities, TCPSocket, RegEx, ByRef and much more. When not working on Android, he’s also spent some time on the Code Editor by improving autocomplete and adding new capabilities such as row highlighting, syntax help area size settings, easier standardize format and selection matching.

Behind the Scenes

Although not as publicly visible, Jason (or JSON as we call him around here), handles the bulk of technical questions that come in through customer support. The personal touch and assistance customers get from him is often lauded by them as something you don’t see from other companies.

You may not have noticed many mentions of Travis above, but he’s been hard at work in Xojo’s kitchen, cooking up things you’ll likely see in 2025.

Matt and Geoff work diligently to keep the docs updated with Xojo’s many changes and improvements.

(This bit is from Paul, since Alyssa won’t write about herself.) Lastly, Xojo wouldn’t exist without Alyssa keeping things operational. From dealing with general customer support issues to social media, licensing, marketing, accounting and even more I can’t think of, Alyssa is the glue that holds Xojo together. The rest of us nerdy introverts really appreciate everything she does.

Thank You

This is all made possible because of the one-of-a-kind, amazing Xojo community. To those of you who have supported Xojo through the years, and to the new users out there finding and enjoying Xojo, we thank you! We wish everyone a lovely holiday season and we look forward to seeing you in 2025!

The Xojo Team

Geoff, Jason, William, Alyssa, Robin, Paul, Travis, Javier, Ricardo, Matt & Gabriel

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Using a WebPopupMenu with a Keyboard

2024r4 comes with keyboard full support for WebPopupMenu. We’ve been gradually improving this control to allow your users to select a field using the arrow keys, for example. What’s new is being able to go directly to one of the item just by starting to type its name.

Memory Usage Improvements

Everyone does their best to avoid leaking memory but, sometimes, that’s just not enough.

Jérémie Leroy is known for the success of the mobile apps he makes with Xojo. When one of these successful app requires a Web Service, receiving 1000s of requests, it needs to be as lightweight as possible.

Thanks to his reports, the visual controls will be creating Tooltip and WebCSSClasses instances only when being used. For many projects this won’t make a difference, but having a Web project with hundreds of concurrent users will surely lead to less memory pressure, allowing to run Web apps in cheaper servers.

This task never ends. Upcoming releases will continue improving memory usage and performance.

WebMapViewer

The library we use to display maps, MapLibre, has been upgraded from 3.2.0 to 4.7.1, which will make much easier to implement some of the features we want to introduce in upcoming releases. Stay tuned!

This control also received 4 additional bug fixes. One of them was causing the Zoom to be modified, when updating another control property, for example.

Some New Features

While Web received mostly bug fixes this time, it also comes with some hidden gems.

Popover position can be adjusted now when displaying it. The positioning is relative to its parent control. Additionally, you can now use a WebPage as the parent control, instead of one of the page children, to place your Popover exactly where you need.

Last, but not least, my favorite new feature. We’ve added CallLater method to WebTimer. It works exactly the same as Timer.CallLater, but it’s Session aware. This means you will be able to access the Session from its callback, without having to do anything special.

Wrapping Up

We are saying goodbye to a 2024 packed with improvements for the Web target, with a release dedicated (more than usual) to bug fixing and to make everything more stable. Make sure to check Xojo 2024r4 Release Notes, so you don’t miss anything.

Thanks to everyone reporting bugs, making feature requests and collaborating in the forum!

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

What’s New in Xojo 2024r4

Xojo 2024r4 brings a range of exciting updates that enhance cross-platform development, improve security, and provide more tools for creating dynamic and interactive applications. Here are some of the standout features:

Web Framework
Enjoy smoother and more efficient web applications with updates to Xojo’s Web Framework. Improved memory usage and numerous bug fixes ensure that your web apps run reliably and perform optimally, providing a better experience for your users.

Discover Web Framework Improvements

These updates and enhancements are designed to make your development process more efficient, productive, and enjoyable. Whether you’re building new applications or enhancing existing ones, Xojo 2024r4 provides the tools and capabilities you need to succeed.

Get Started

To learn more about Xojo 2024 Release 4 and begin your development journey, please visit the Xojo 2024r4 Release Notes. The update is available for download now from the Xojo downloads page.

What’s Next?

We’re continuously working on new features, updates, and enhancements to our platform. If you have any suggestions or ideas, please add them to the Xojo tracker. We’re always looking to improve and expand Xojo to better serve our community.

Thank you for being part of the Xojo community. We’re excited to see what you create with Xojo 2024r4!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

In software development, where multiple threads often need to access shared resources like files or databases, semaphores bring order to potential chaos. They prevent data corruption and ensure applications run smoothly and efficiently, even during peak processing times.

Concurrent programming often requires multiple processes to access shared resources simultaneously. Without proper management, this can lead to conflicts and unpredictable behavior. Semaphores offer a solution to this challenge, acting as traffic lights to control access to these shared resources.

Why Use Semaphores?

Semaphores are crucial for:

• Preventing Race Conditions: In concurrent systems, a race condition occurs when the program’s outcome depends on the unpredictable timing of events. Semaphores help avoid this by ensuring that operations on shared resources happen in a controlled order.
• Ensuring Data Integrity: When multiple threads access shared data, there is a risk of data corruption if one thread modifies the data while another is reading it. Semaphores prevent this by allowing only one thread to modify the data at a time.
• Improving Efficiency: Semaphores can improve the performance of multi-threaded applications by reducing the time threads spend waiting for access to shared resources.

Sempahores in Xojo

Xojo provides the Semaphore class for managing concurrency. This class uses a counter to represent the number of resources available.

Here is how to use a Semaphore to protect access to a shared resource:

1. Acquire a Lock: Call the Signal method on the semaphore before accessing the resource. If a resource is available, the thread acquires the lock and continues. If not, the thread waits until a resource becomes available.
2. Perform the Operation: Access and manipulate the shared resource.
3. Release the Lock: Call the Release method on the semaphore after you finish with the resource. This action makes the resource available for other threads.

Example:

Let’s say you have multiple threads that need to write to the same file. Using a Semaphore, you can ensure that only one thread writes to the file at a time, preventing data corruption.

Initialization
Define a Semaphore in the application class to control file access to an important file

Public Property FileAccess As Semaphore 

Initialize the semaphore in the App.Opening event handler with a count of 1, meaning only one thread to access the file at a time

Sub Opening() Handles Opening
  FileAccess = New Semaphore(1)
End Sub

Access in Threads
Use the Semaphore in a thread to safely read from or write to the text file.

Sub Run() Handles Run
  // Acquire the semaphore to access the file
  App.FileAccess.Signal
  
  Try
    // Perform file operations
    WriteTextToFile(SpecialFolder.Desktop.Child("important_file.txt"), "This is a line of text.")
  Finally
    // Release the semaphore to allow other threads access
    App.FileAccess.Release
  End Try
End Sub

Public Sub WriteTextToFile(f As FolderItem, text As String)
  // Helper method
  
  Var outputStream As TextOutputStream
  
  Try
    If f.Exists = False Then
      outputStream = TextOutputStream.Create(f)
    End If
    outputStream = TextOutputStream.Open(f)
    outputStream.WriteLine(Text)
    
  Catch e As IOException
    // Handle file I/O errors
    MessageBox("Error writing to file: " + e.Message)
  Finally
    If outputStream <> Nil Then
      outputStream.Close
    End If
  End Try
End Sub

Benefits of Semaphores in Xojo

Using Semaphores in Xojo applications offers numerous advantages:

• Resource Fairness: Ensure fair access to shared resources among all threads.
• Resource Management: Control access to shared resources, preventing conflicts and ensuring data integrity.
• Performance Optimization: Reduce wait times and improve overall application speed by limiting concurrent access.
• Efficient CPU Utilization: Prevent unnecessary CPU usage by allowing threads to wait without consuming resources.
• Enhanced Responsiveness: Create a more responsive user interface by ensuring smooth execution of critical code.
• Improved Scalability: Maintain performance even as resource demands increase.
• Thread Synchronization: Coordinate the execution of multiple threads for predictable program behavior.
• Deadlock Prevention: Avoid situations where threads wait indefinitely for each other.

Conclusion

Semaphores are essential tools for managing concurrency in Xojo applications. They provide a simple yet powerful mechanism for controlling access to shared resources, preventing race conditions, and ensuring data integrity. By incorporating semaphores into your multithreaded Xojo applications, you can achieve better performance, reliability, and scalability.

Don’t forget to check the official Xojo documentation about Semaphore at https://documentation.xojo.com/api/language/semaphore.html

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

LX Aer is an AI-powered educational platform developed by student-turned-entrepreneur Leo Medvinsky. In 2020 as the pandemic forced schools to begin using remote learning tools, Leo, a student at the time, saw the gaps and the flaws in the tools he was offered and did what so many Xojo developers do, he decided to build something better. A quick view of LX Aer demonstrates it’s the solution someone who actually uses such a system would create. LX Aer is a modern take on the LMS with a user interface that centers the student and teacher. Currently, LX Aer uses Xojo Web for the backend and the project has 30,000 lines of Xojo code and growing.

10 Questions with Leo Medvinsky of LX Aer

Using Xojo Web for just the backend (web services) is somewhat surprising, tell us about that?

The LX Aer web app is designed to be the digital hub for students, teachers, and soon, administrators. The original web app was written in between 2020 and 2021 and used Xojo Web for some web service work but was mainly used the conventional way for Xojo Web pages. To increase speed and reliability as well as to improve performance, the decision was made that our next product (a standalone attendance tracking system) would be written using Xojo Web as a backend, with a Xojo iOS app and a standard HTML/CSS/JS web app to accompany it. We found that Xojo Web was a great way for us to have business logic on the backend, with great performance and amazing ease of management with Tim Parnell’s Lifeboat. When, in 2022, we were unifying this attendance system into the LX Aer suite, it was decided that the LX Aer suite would be combined into the attendance technology stack, rather than the other way around. This was a large time investment as it involved rewriting and rethinking significant portions of the existing product offering but has brought our software to a much stronger position.

What is your experience with Xojo Web performance for larger scale apps like LX Aer?

Up until recently, when we began self-hosting most things, we had two instances of the LX Aer Backend running on a Debian server in AWS with just 2 GB of RAM and performance was very good. We are actively developing solutions to allow for much greater scalability and distribution of load across not just instances (with Lifeboat), but across several different servers. Our database server runs CubeSQL, and Marco and I have been discussing ways to implement database sharding into CubeSQL to allow for greater scalability. While we are a startup without too many users right now, LX Aer needs to be able to support the thousands of users each school brings, along with all of their data requirements.

Can you tell us why Xojo was chosen as the backend and what other options were ruled out?

My first programming language was Visual Basic .NET. The original software I had was a simple quizzing application designed to help the user study for tests, but it could only run on Windows. This was a significant limitation. I (mostly) loved the syntax of VB compared to other languages I’ve worked with (Python, C++, Swift…), so I decided to try Xojo when I came across it in 2020. It was an amazing feeling to be able to write with the syntax I already knew to and make an iOS app, albeit a limited one, the same day I downloaded Xojo. Having experimented with Xojo, I started working on major projects in it very soon, and when a web development need came up, it was my go-to. Over the years, I have considered many alternatives, and many in the developer community (not Xojo’s) have discouraged me from relying on a proprietary language for such critical software, but I have never had any interest in switching. Every step of the way, Xojo has scaled with our needs.

Mac, Windows or Linux?

I flip-flop constantly between my dev machine, a Mac, and my business machine, a Surface. I tried many Linux distros on several occasions and have never been much of a fan of it as a consumer operating system.

What do you wish more people would ask/talk to you about when it comes to LX Aer?

Security. LX Aer’s tagline is “Security, Reliability, Innovation.” Notice how “security” comes first. While the Aer Intelligence platform offers incredible AI tools built into LX Aer to improve educational outcomes, and this is one of the largest attention grabbers, I would argue that security is our most interesting innovation. Having graduated from high school just over a year ago, I recall when I found my student data leaked online after a massive breach of PupilPath, a learning management system that my school used at the time. I also recall the school I transferred to for my senior year and the software they used, Genesis, which allows a user to view their own password in plaintext after logging on. This, among other things, motivated me to always put security first. In 2023, we launched LX SecurShield, which provides encryption for student data WITHOUT storing keys on the server, while still allowing a user to seamlessly log on from any device, without any of the hassle typically associated with client-side encryption. LX SecurShield is truly unique and is something I wish more people took an interest in.

How would you explain your most recent project to a 5-year-old?

LX Aer is creating an AI chatbot that will help teachers teach and students learn!

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

Tough question… maybe French?

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

I’ve always been technically minded, but I have seen it as a means to an end, rather than the end itself. I never wrote code for the sake of writing code. I always had a long-term project in mind. LX Aer has been a project of mine for over 4.5 years, and has changed immensely from March 2020, when it first began. Consequently, the programming moments that made me think how much I love my job were when I was able to finally push an innovation over the edge into a working state. When I was developing LX SecurShield, it required significant portions of LX Aer to be rewritten to support the new encryption. After developing a proof of concept, I worked almost nonstop for close to a week to develop it into a usable and stable state, with several all-nighters along the way. At the end of it all, I thought, “wow, I love my job so much, even with all the craziness associated with it!”

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

10 years ago, I was 8 and had no experience writing code (though I was still the go-to tech support for my friends/family). This is a tough question, but if I had to pick it would be the difference in writing code for someone else vs. writing code for your own company. Writing code for someone else is 1,000x more difficult than writing code when you’re your own boss. As for something in the industry itself, I am always surprised by the tendency of web developers to jump around from platform to platform… Angular, React, etc. It just fascinates me.

What is a piece of software more people should know about?

To those in the Xojo community writing a web service, I cannot recommend Tim Parnell’s Lifeboat and Marco Bambini’s CubeSQL enough. To anyone working with cryptography, Björn Eiriksson’s Einhugur plugins are just incredible! 

To people in general, I think it would be great if more people knew about Proton. They’re a Swiss company that develops mail, cloud storage, calendar, VPN, and password storage software, all of which uses client-side encryption and is easy-to-use. They were my inspiration for LX SecurShield. 

What’s something you worked on recently that you are excited about?

It would be somewhat cliché to say that I am excited about AI (Aer Intelligence), but I am. Especially in the EdTech industry, I see so much potential for it to improve educational outcomes and make lives easier for overworked teachers.  With our software having won the Pitchfest award at the prestigious Future of Education Technology Conference this year, I believe, largely because of our AI capabilities, I think it isn’t just the LX Aer team that’s excited about AI in education.

Thank you to Leo Medvinsky for answering our questions. If you want to learn more about LX Aer visit https://www.lxaer.com/. To all those in the Xojo community, as a token of gratitude, Leo is offering a free license until December 31^st, 2024. Email sales@lxaer.com and say that you’re part of the Xojo community! “Although I have not been very active in the Xojo community in terms of engagement,” Leo says, “without the exceptionally great resource that is the Xojo Programming Forum, as well as the software and plugins made by those in the community, such as Tim Parnell, Marco Bambini, Christian Schmitz, Björn Eiriksson, and Sam Rowlands, none of this would have been possible.” See the full LX Aer Xojo community credits at https://www.lxaer.com/credits.

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

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

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

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

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

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

Building for Windows ARM with Xojo

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

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

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

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

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

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

Presented with choosing what development tool is best for your main, full-stack development needs, let’s discuss the benefits of Xojo development platform for your next web project. With its simplicity, flexibility, and powerful features, Xojo will help you create high-quality web applications quickly and efficiently, with the added bonus of covering backend and frontend development in the same IDE—no more language switching—while also lowering your overall costs.

Overview of Full-Stack Development

Full-stack development covers the entire spectrum of technologies and skills required to create a fully functional web application. This approach involves both the frontend, which users interact with directly, and the backend, which powers the application.

At its core, full-stack development refers to the ability to work on both the client-side and server-side of an application. This means that full-stack developers should be proficient in frontend technologies such as HTML, CSS, JavaScript, as well as backend technologies like Node.js, Python, and frameworks such as React and Django. Full-stack developers possess a broad skill set that includes designing user interfaces, managing databases, and server logic, enabling them to oversee the entire development process.

Usually, a full-stack developer handles:

• Frontend Technologies: These consist of HTML for structure, CSS for styling, and JavaScript for interactivity, crucial for crafting engaging user interfaces. Frameworks such as React, Angular, and Vue.js are also typical choices for building dynamic web applications.
• Backend Technologies: This segment covers server-side programming languages like Node.js, Python, Ruby, and PHP, coupled with frameworks such as Express, Django, and Ruby on Rails, essential for robust backend development. Databases, both relational (e.g., MySQL, PostgreSQL) and NoSQL (e.g., MongoDB), are also crucial for data management.
• APIs (Application Programming Interfaces): APIs enable simple communication between frontend clients and backend applications/servers, facilitating the exchange of data. RESTful APIs and GraphQL are common approaches used in modern web applications.

Advantages in adopting a full-stack approach in software development:

• Faster Development Cycles: With a single developer or a small team capable of handling both frontend and backend tasks, projects can progress more quickly, reducing the time to market.
• Easy Integration: Full-stack developers have a comprehensive understanding of how the different components of an application interact, leading to better integration and fewer compatibility issues.
• Enhanced Problem-Solving: By possessing a complete view of the application, full-stack developers can identify and resolve issues more efficiently, improving overall project quality.

Why choose Xojo as a full-stack development solution?

When it comes to full-stack development, selecting the right programming language(s) or frameworks can significantly impact the efficiency and effectiveness of your projects. Xojo is a powerful choice for anyone seeking a robust, user-friendly and versatile development environment that provides everything needed to transform their ideas into fully fledged, working software products, no matter the platform or environment.

Xojo features ideal for full-stack development:

• Built-in Web Server: Xojo has its own built-in web server that allows developers to easily test and deploy web applications (on Linux or Windows servers) without the need for additional software. There is no need to set up complicated web server technologies or deal with compatibility issues and security. Xojo handles all of that for you. In production, you can run a web app built with Xojo as stand-alone or behind Apache or Nginx. You decide what works best for your project.
• Visual Development Environment: Xojo offers a visual development environment that allows developers to design user interfaces using drag-and-drop elements. This approach simplifies the process of creating appealing applications, accessible to both novice and experienced developers.
• Object-Oriented Programming: Xojo is object-oriented programming (OOP), enabling developers to create modular and reusable code. OOP encourages better organization and maintainability of applications, making it easier to scale projects over time.
• Compiled Code: Xojo compiles code into machine code, which results in fast and efficient web applications. In the event that some bad actors gain access to your server, rest assured that Xojo built web apps are more secure than those built with other tools.

In addition to these features, while many programming languages cater to full-stack development by combining and utilizing multiple external solutions, Xojo distinguishes itself as an ideal, singular solution. Compared to languages like JavaScript, Ruby, PHP or Python, Xojo has a gentle learning curve, making it an attractive option for beginners. Its syntax is straightforward and resembles natural language, which helps new developers learn concepts quickly. Xojo’s visual tools and drag-and-drop features enable developers to prototype applications rapidly. This is particularly advantageous for startups and businesses looking to iterate and launch products quickly.

Xojo for Frontend Development

Creating an engaging and user-friendly frontend is crucial for any web application. With Xojo, developers can quickly prototype and design visually appealing interfaces without the need for 3rd party tools or additional frameworks.

Xojo’s visual development environment makes building user interfaces an easy and enjoyable thing. With its drag-and-drop interface, developers can easily design and layout their GUI components- buttons, labels, and text fields- without needing any code at all. This intuitive approach allows developers to focus on the logic of the application rather than getting bogged down by low-level details.

So, what makes Xojo’s frontend capabilities so effective? For starters, it allows frontend developers to quickly:

• Prototype and test ideas without writing code;
• Easily create complex layouts and designs;
• Focus on the logic of the application rather than the UI;
• Collaborate more effectively with designers and other team members.

Example: A simple web app frontend built with Xojo

To illustrate the power of Xojo’s visual development environment, let’s take a look at a simple web app frontend built using Xojo. In this example, we’ll create a basic to-do list application with a user-friendly interface without writing any HTML, CSS or JavaScript code.

Coding Backend Functionality and Connecting it to the Frontend

While users interact with the frontend of apps, it’s the backend that does the heavy lifting, handling data and core functionality. Xojo makes building these backend systems easier for developers with useful features that create efficient server-side applications without unnecessary complexity. Xojo is a practical choice for developers who want to build solid, functional backends for web (and even desktop or mobile) apps without getting bogged down in overly complicated processes. Here are some notable aspects:

• Database Integration: Xojo supports out-of-the box connections to a variety of databases, including MySQL/MariaDB, PostgreSQL, SQLite, and ODBC. Besides the built-in database classes, now there’s also the DBKit project and the new DatabaseConnection project item.
• RESTful API Creation: Xojo makes it easy to create RESTful APIs, which are essential for enabling communication between the frontend and backend of a web application. By defining endpoints and handling HTTP requests and responses, developers can facilitate data exchange and enhance the interactivity of their varied applications and clients (web, desktop or mobile).
• Session Management: Managing user sessions is crucial for web applications, especially those that require user authentication. Xojo provides built-in support for easy session handling, allowing developers to track user activity and maintain state across different pages, improving the overall user experience.

Integrating the Frontend and Backend

Full-stack development works best when the frontend and backend of an app work well together. Xojo makes this easier by offering a single app development software solution for both parts. Developers can use the same programming language throughout the whole project, which saves time and reduces complications. This approach helps programmers focus on creating a smooth user experience without switching between different tools or languages.

Here are some key points worth taking into account when you want to start building your next successful application:

• Unified Language for Development: One of the standout features of Xojo is that it allows developers to work in one programming language, eliminating the need to switch between multiple languages like HTML, CSS, or JavaScript. This means that both the frontend and backend logic can be implemented using Xojo’s straightforward syntax, streamlining the development process, no matter the OS platform they’re building for.
• Single Integrated Development Environment (IDE): Xojo’s IDE serves as a centralized hub for managing both frontend design and backend coding. Developers can design user interfaces visually, drag and drop elements, and simultaneously write the corresponding backend code without needing to leave the IDE. This integration enables a more intuitive workflow, reducing the chances of errors and inconsistencies.

As the demand for agile and efficient software development continues to rise, the choice of programming language solutions and frameworks can have a significant impact on both project timelines and budgets. Xojo stands out as a compelling alternative for developers and teams accustomed to traditional stacks like LAMP (Linux, Apache, MySQL, and PHP) or MEAN (MongoDB, Express.js, Angular, and Node.js) or any other.

For organizations and startups already familiar with other development stacks, transitioning to Xojo can lead to significant savings in training costs. Xojo’s intuitive interface and single programming language approach mean that team members can quickly adapt without needing extensive retraining. This is especially beneficial for companies looking to onboard new developers or expand their teams. And as an extra plus, using Xojo, you can expand your application supported platforms to include building native desktop clients (Mac, Windows, Linux) or mobile clients (iOS, Android) , all with just one codebase.

And let’s not forget that managing a full-stack application typically involves maintaining multiple technologies, which can result in higher operational costs. Xojo minimizes the need for additional languages and frameworks, resulting in lower maintenance overhead costs and increased efficiency in full-stack development. Updates, debugging, and scaling become more straightforward, allowing teams to allocate resources more effectively.

Is it fair to call Xojo not just a great full-stack development suite but a full-stack development suite that truly optimizes the entire development process and maximizes productivity?

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!

Control Sets

There are cases where you have a bunch of controls with the same functionality. Imagine you are coding a calculator and you’ve just added the WebButtons for each digit. It would be repetitive and error prone to add the same code to Pressed events, on each button when the only thing that changes is the numeric value.

A set of controls can be grouped, so you can think about them like if you were using an array. You can add event handlers to the group itself. Events will be enhanced with an “index” parameter, to help you decide what to do, depending on the element.

Create Tabs and Embed Controls at Runtime in WebTabPanel and WebPagePanel

Same as with Control Sets, this is something that was already present in Desktop projects and we wanted to include it for Web. From now on, you will be able to create and remove tabs and pages in WebTabPanel and WebPagePanel controls, respectively. Controls can also be added and removed at runtime, or move controls between tabs or pages whenever you need.

This opens a new world of possibilities for your applications, where you can provide your end users a way to have multiple contexts open at the same time.

WebListBox: Configurable Header and Row Height, Border and Line Style

You will be able to configure the height of WebListBox headers and rows with the same API you are used to using in your Desktop projects. You won’t need to tweak them with CSS anymore.

HasBorder and GridLineStyle has also been added to Web projects, allowing you to remove the outside border, display only vertical lines between the columns… or just remove them.

WebDataSource Interface

Speaking of WebListBox improvements, you’ll find that the WebDataSource is easier to implement. You won’t need to implement SortedPrimaryKeys and UnsortedPrimaryKeys methods anymore.

There are only three methods required now:

• ColumnData: Where you will define the amount of columns, names, and configure if they are sortable
• RowCount: So the control can now the amount of space it will need
• RowData: This is where you return an array of rows

WebListBox lazy load rows, meaning that it will only ask your DataSource for the amount of rows being displayed on screen. It will only fetch more when needed.

WebListBox Improvements When Using a WebDataSource

Using a WebListBox with a DataSource makes it possible to display very large amounts of data. Until now, you were able to display thousands of rows very quickly. This release improves the way Xojo uses your DataSource, without having to change a line of code in your projects.

Scrolling through the data will display the rows much faster than before. Just for comparison, 2024r1.1 was able to display 1 million rows in about 6 seconds in my computer. The same project, using 2024r2, can display them in less than 100ms.

But is not just the speed that has been improved. Its memory footprint has been dramatically reduced as well. Displaying 1 million records in 2024r1.1 used about 1 GB of RAM, where 2024r2 will use just a few MB instead.

I can’t imagine a use case where you need to display millions of rows and scroll through them. But if you find one, you will be able to implement it with Xojo

WebButtons Can be Resized Now

In order to make it easier to migrate your Web 1 projects, you will be able to modify the height of your WebButtons. The web framework will also take care to reduce the font size if needed when the button is smaller.

Individual Indicator for Each Segment of WebSegmentedButton

There are situations where you want to mix different “indicators” (different colors) in a single WebSegmentedButton control. For example, pressing on one of the segments can be a destructive action, so you could use the Danger indicator. By default, segments will use the indicator you set in the Inspector panel, but you will be able now to individually override one of them.

Me.Indicator = WebUIControl.Indicators.Primary
Me.SegmentAt(1).Indicator = WebUIControl.Indicators.Danger
Me.SegmentAt(2).Indicator = WebUIControl.Indicators.Success

Having 4 segments, this will be the result of above example at runtime:

Outlined WebButton and WebSegmentedButton

Some GUIs could become overwhelming, when every button looks like a call to action. The new Outlined property, available in WebButton and WebSegmentedButton controls, can help with heavily loaded interfaces. Here is how it looks like:

Performance, Memory Leaks, Bug Fixes

Last, but not least, 2024r2 comes with great performance improvements. We’ve been improving the web server to handle even more requests per second. If you are using Xojo Web for exposing an API, it will be able to serve more requests in less time. For regular Xojo Web applications, it means it will be able to handle more events and reply to them faster.

Here is a comparison of the same project during the different releases of Xojo:

Latency has also been improved, Xojo is able already to reply in less than 2ms:

If you are still serving Web APIs with Web 1, this is a good opportunity to migrate:

That’s a Wrap!

As usual, I’d like to send a big thank you to everyone taking the time creating bug reports, feature requests and testing beta releases. This wouldn’t be possible without your support.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

There are many ways to develop with Xojo and use database servers. You might be working on a multi-user desktop application that stores data in a database. Or you’re creating a multi-user Xojo Web application that needed to be scaled up to a couple of running instances – and use a database for data storage. Or maybe you’ve written a mobile application that connects to a Backend REST API – again possibly written in Xojo (e.g. with the open source Express, or with Xojo Web).

As a Developer

When working on such projects, you’re facing quite some challenges with the various database servers available.

• You need to have a local development environment running the database server(s).
• You want to test your application against a newer version of a database server.
• A customer reports an issue occurring with a database server version that you don’t have installed.

Developer Machine

I like to have a development machine that’s as cleaned up as possible. So I don’t like the idea of installing various servers just for some tests. It’s so tedious to clean up, update to other versions, and remove all remnants of an installation when no longer required. And I don’t want to have various services running on my machine that I don’t need all the time, as they’re just eating precious memory and slowing down the machine.

Wouldn’t it be cool if there was an easy way to spin up various database servers when needed without all the hassle? Well there is – let’s have a look at Docker and Docker Compose.

Docker Compose and Database Servers

With Docker, it’s a breeze to develop with and for various database servers.

What is Docker?

If you haven’t heard of Docker, go ahead and read their excellent Documentation: Docker – Overview. Or read my previous Guest Blog Post: Running Xojo Web Applications in Docker. I’m just going to repeat and quote some basics from the Overview to get a very brief introduction:

Docker is an open platform for developing, shipping, and running applications. It provides the ability to package and run an application in a loosely isolated environment called a container. The isolation and security allow you to run many containers simultaneously on a given host. Containers are lightweight and contain everything needed to run the application, so you do not need to rely on what is currently installed on the host.

A Docker Container is a runnable instance of an image. You can create, start, stop, move, or delete a container. By default, a container is relatively well-isolated from other containers and its host machine. You can control how isolated a container’s network, storage, or other underlying subsystems are from other containers or from the host machine. A container is defined by its image as well as any configuration options you provide to it when you create or start it.

Docker Compose is a tool for defining and running multi-container applications. It is the key to unlocking a streamlined and efficient development and deployment experience. Compose simplifies the control of your entire application stack, making it easy to manage services, networks, and volumes in a single, comprehensible YAML configuration file. Then, with a single command, you create and start all the services from your configuration file.

Docker Compose for Database Server and Administration

This sounds great. Just write a YAML configuration file, and run a database server on the host (meaning: your developer machine). And be able to start, stop, delete at any time – without messing with Preferences, Launch Daemons.

But why Docker Compose for “multi container applications”? Well, the database server is one part: one application, one running docker container. And as a developer you most likely want to have some database administration tool running, too – which again is running as an own isolated container. And in order to have both available with a single command (or by simply pressing “run” or “stop”) we’re going to “compose” these two parts so that they fit and work together.

How to Run a Database Server and Administration Tool with Docker Compose

Let’s do that and install and configure three database servers which we then can use to develop an application in Xojo to connect to:

• PostgreSQL & pgAdmin
• cubeSQL & cubeSQL Web Admin
• MariaDB & phpMyAdmin

Note: All the following configuration files are available on GitHub: jo-tools/docker.

Requirements

Obviously we need to have Docker installed. And since we’re talking about being a Developer and doing this on our own development machine we’re going to install Docker Desktop. With Docker Desktop you can later easily start, stop and delete the Containers we’re going to create. When it’s empty (no containers installed), it looks like this:

We’re now ready to get started…! But wait – there is one thing we should talk about before.

Data Storage

Where are the database servers going to store their data(bases)?

If you want to know all the details, head over to the Docker Documentation: Manage data in Docker. What we need to know is this:

Docker has two options for containers to store files on the host machine, so that the files are persisted even after the container stops: Volumes, and Bind Mounts.

Why is this important to know? Well, let’s assume we create and start a Container “PostgreSQL Server”. Think of that Container as a “virtual machine” or a bag. It can save data in there just fine. But once we delete that container or throw away that bag, then all it’s data is gone, too.

That might well be intended…! For example if you just wish to play with some tool and don’t care to keep the data you’re creating with it. However, if you’d like to easily back up that data, or update a Container from “v.15” to “v.16” and keep the previous data – then that’s when Volumes and Bind Mounts are needed.

Quoted from the docs:

Volumes
Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. They are completely managed by Docker.

Bind Mounts
Data is stored in a directory on the host machine, which is mounted into the container.

Okay – two options, so what’s the difference?

The Bind Mounts are a folder on the host (your developer machine). So you can easily see them, view/edit/backup the data. It might be an option if you need easy access to these files.

The Volumes are the preferred way, since they are managed within Docker. Using Docker Desktop you can view the contents – but it’s not that simple to view/edit files in there as you can’t mount it as a volume or folder on your developer machine. Of course there are some more advanced ways, which I’m not going to explain here. So definitely the best option when you don’t need to work with and open these files with other tools, too. The other reason we don’t need Bind Mounts for our database servers is that we can just use their administration tools to import/export data such as database dumps.

Alright – now let’s start and set up some database servers.

PostgreSQL Server & pgAdmin

Let’s use the example setup with Volumes for Data Storage from here: GitHub: jo-tools/docker – local-postgres-volumes.

Download the docker-compose.yml file from my GitHub Repository and place it in a folder on your machine.

I’m going to save it in: ~/Docker/local-postgres-volumes

YAML file: docker-compose.yml
A word of precaution when writing and editing YAML files:

• Indentation is done by spaces (not by tabs!)
• Indentation has to be exact (use always 2 spaces), or expect to get syntax errors

Let’s look at the content of this docker-compose.yml.

x-common-timezone: &services-timezone Etc/UTC

name: local_postgresql
services:
  postgres-server:
    container_name: postgresql
    hostname: postgresql
    image: postgres:16-alpine
    volumes:
      - postgresql_data:/var/lib/postgresql/data
    environment:
      TZ: *services-timezone
      PGTZ: *services-timezone
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
      POSTGRES_DB: postgres
    networks:
      - local_postgresql_net
    ports:
      - 5432:5432
    restart: unless-stopped

  pgadmin:
    container_name: pgadmin4
    hostname: pgadmin4
    image: dpage/pgadmin4:8
    environment:
      TZ: *services-timezone
      PGADMIN_DEFAULT_EMAIL: admin@postgres.sql
      PGADMIN_DEFAULT_PASSWORD: admin
      PGADMIN_CONFIG_UPGRADE_CHECK_ENABLED: "False"
      PGADMIN_CONFIG_SERVER_MODE: "False"
      PGADMIN_CONFIG_MASTER_PASSWORD_REQUIRED: "False"
    networks:
      - local_postgresql_net
    volumes:
      - pgadmin4_data:/var/lib/pgadmin
    ports:
      - 5433:80
    restart: unless-stopped
    depends_on:
      - postgres-server

volumes:
  postgresql_data:
    driver: local
    name: postgresql_data
  pgadmin4_data:
    driver: local
    name: pgadmin4_data

networks:
  local_postgresql_net:
    name: local_postgresql

In the first hierarchy there are:

• x-common-timezone: &services-timezone Etc/UTC

In this extension we define a scalar value for the timezone, which will be used for the environment variables in both services. The template uses UTC (which is also the default for Docker). You can change it to your timezone, e.g.: Europe/Zurich. This might be desired if you’re going to select the current date/time from the database server later.
• name: local_postgresql

That’s the name of this “setup”. We’ll later see this in Docker Desktop’s Containers. There we can also start/stop/delete this setup at any time.
• services:

There are two services in this setup: postgres-server and pgadmin
• volumes:
And two volumes: one for the database server, and one for the administration tool.
• networks:

Both these two containers will be in the same network.

When we look at the two services postgres-server and pgadmin4:
• container_name:
The name of the Container. We’ll later see this as a sub-element of this docker-compose setup named local_postgresql
• hostname:
Think of a container as a virtual machine. Every one has its hostname. And the two containers in this setup we have placed in the same network. So they can talk to each other via hostname.
•image:
That’s basically the content of the container. We’re going to install:
• postgres:16-alpine
PostgreSQL Server in Version 16.x, running on Linux Alpine (a very lightweight one).
• dpage/pgadmin4:8
pgAdmin 4 in Version 8.x as the administration tool.
• environment:
Here the environment variables of the containers are being defined. TZ defines the Timezone, and uses the value we have defined in the extension on the very top. The other Environment Variables contain the defaults and standards – here used when the containers are being started the first time to define the default logins, users and passwords. Our PostgreSQL server will have a default login with both username and password: postgres. pgAdmin we have configured to auto-login without authentication required, and disabled update checks.
• networks:
Remember – both in the same one (defined below)
• volumes:
The format here is: volume_name:/mount/in/folder
We’re going to see these volumes later in Docker Desktop. They’ll contain the data. Usually the documentation of the Docker Images explain which folders are being used to save data, so they can be mounted here to either a Volume (or a Bind Mount).
• ports:
The format here is: host-port:container-port
For PostgreSQL Server we’re using 5432:5432, meaning that we can connect on our developer machine to Port 5432 (and this will be forwarded to the container running PostgreSQL Server, listening on Port 5432 inside the Container). pgAdmin is running on Port 80 within the Container, but we connect to it from our developer machine via Port 5433.
• restart: unless-stopped
This basically means: if you have this setup running and reboot your host (developer machine), then this setup gets restarted automatically. If you’re going to stop this setup (because you don’t need it at the time), then it’ll be stopped after a reboot, too.

Start Docker Compose Setup

As we can’t use Docker Desktop to start a Docker Compose setup (maybe this feature will be added in the future) we have to use Terminal. Change Directory to where the docker-compose.yml file is and type: docker-compose up -d

The referenced Images will be pulled, the defined network created and the Containers started.

Open the Dashboard in Docker Desktop and look at the Containers – you’ll find our setup named local_postgresql with the two Containers postgresql and pgadmin4:

They are currently up and running.
If you want to stop this setup simply press the button under “Actions”. It then will be stopped even after a reboot. And should you need to run the setup again later, just hit the button “Run” here.

Under Volumes we see the created ones:

You can click on one to see it’s contents – here the data of postgresql:

Connect With PGADMIN4
Either switch again to “Containers” and click the link “5433:80” in the column “Port” of the Container “pgadmin4” in Docker Desktop, or open a browser and go to 
http://localhost:5433.

Since this is the first launch of pgAdmin4 we need to add a server – I have given it the name “Docker”:

In the register “Connection” we have to enter the connection data:

Username and password are the default ones (remember the environment variables?). And for this local developer setup I have chosen to save the password.

The most interesting part is the hostname.

• You can’t use localhost here!

  The reason is simple: pgAdmin is running in a Container (think of it again as a virtual machine), so it’s “localhost” is the Container running pgadmin4. Not your developer machine, and not the Container where postgres is running.
• I have entered: host.docker.internal

  This is explained in the Docker Documentation: networking:
The host has a changing IP address, or none if you have no network access. We recommend that you connect to the special DNS name host.docker.internal, which resolves to the internal IP address used by the host.
• Another option would be to just use the hostname: postgresql

  And why does this work? Well – we have configured these two containers to be in the same network, and the server is running in the host named “postgresql”.

And here we go: Let’s expand the entries of the just added server “Docker”, click on the main database “postgres” and execute a query: SELECT version();

Connect with Xojo
We’re ready to use Xojo now and work on applications using our local PostgreSQL Server.
Let’s connect to our local development server running in Docker. As a simple test I have placed the following code in the Opening event of a Label:

Var db As New PostgreSQLDatabase
db.Host = "localhost"
db.UserName = "postgres"
db.Password = "postgres"
db.Port = 5432

Call db.Connect

Var rs As RowSet = db.SelectSQL("SELECT version();")
Me.Text = rs.Column("version").StringValue

Additional Information

You’ve seen how to easily spin up PostgreSQL with Docker Compose and connect to it with pgAdmin4 and Xojo. What else do we need to know?

Images
You’ll find available Images on Docker Hub. In the above setup we have used postgres and pgAdmin4. If you look at them on Docker Hub you’ll see that they provides many images. One can select them by Tag. The used Tag “postgres:16-alpine” here means that we get the latest version 16 (e.g. 16.2, and some month later maybe 16.3 or 16.4). If for some reason we want to get exactly version 16.1, then we can use the corresponding Tag, e.g. “postgres:16.1-alpine”.

A Setup using Bind Mounts
If you’re going to try the docker-compose.yml with Bind Mounts from here: GitHub: jo-tools/docker – local-postgres-bindmounts, then you’ll notice the difference in the configuration here:

volumes:
  - ./postgresql_data:/var/lib/postgresql/data

You won’t get a Volume in Docker, but instead this will create a folder named postgresql_data in the folder where you’ve placed docker-compose.yml and launched the setup with docker-compose up -d.

Docker Compose Commands
We’ve already mentioned that the first launch of a Docker Compose setup will require Terminal. The following commands are to be executed in the same directory containing the yaml file, too:

docker-compose up -d
This looks for the file docker-compose.yml, pull the images, do all the setup and launch the containers. You can also use this command to restart this setup, should you have stopped it.

docker-compose stop
Stops all services in this setup. Or do it using the buttons in Register “Containers” in Docker Desktop.

docker-compose down -v
This removes all services and volumes from this setup. Use this to get rid of all Containers, Volumes AND data. Haven’t we mentioned that – it’s super easy to clean up
You could also click the Delete buttons in Docker Desktop in both “Containers” and “Volumes” (and optionally “Images”).
If you omit the option “-v”, it will leave the Volumes in place. This might be of interest if you intend to keep the data, in case you’re going to spin up this setup again some time later.

docker-compose down
docker-compose pull
docker-compose up -d
These 3 commands will first tear down the existing containers (leaving volumes and data in place), then pull the latest versions from Docker Hub and set everything up again. Remember that we have used the Image “postgres:16-alpine”, and currently got PostgreSQL 16.2? Once PostgreSQL 16.3 is available we can execute these commands and get the latest version. Again super easy to update, isn’t it?

cubeSQL & cubeSQL Web Admin

Another popular database server for Xojo is cubeSQL. It basically adds multi-user handling (including groups, privileges, und much more) on top of SQLite.

cubeSQL is a fully-featured and high-performance relational database management system built on top of the SQLite database engine.

It is the ideal database server for both developers who want to convert a single user database solution to a multi-user project and for companies looking for an affordable, easy to use and easy to maintain database management system.

You’ll find an example setup for Docker Compose here: GitHub: jo-tools/docker – local-cubesql-volumes. To connect with Xojo you need a plugin, which can be downloaded from GitHub: cubesql/cubeSQLAdmin

cubeSQL Web Admin – Written with Xojo Web

cubeSQL has a desktop application for administration, which you’ll find in the above GitHub Repository, too. As you can guess a desktop based application is not quite convenient when it comes to an easy docker compose setup.

While I’m using Xojo for desktop and console applications for quite some time, I’ve never really used Xojo Web before. That’s why I took this opportunity and gave it a try. And behold – in very short time (most functionality in just a weekend’s leisure time) I’ve written “Xojo Web Admin“. It’s been a pleasure to create something more than just some simple examples – I like the idea of creating something useful even while learning something new. And I’ll be honest – I’ve found a couple of bugs in Xojo’s Web Framework while writing cubeSQL Web Admin, but most of them are already fixed and implemented for the next Xojo version. And finishing and polishing the project to make it available to the public also took an additional couple of evenings.

cubeSQL Web Admin is Open Source – so go ahead and have a look at the source (or even better: contribute to it by adding more features, find bugs and fix them). There might be some things of interest, such as:

• How to use Xojo Web to build an app that runs in a Docker container.
 See also this Guest Blog Post: Running Xojo Web Applications in Docker
  • A new feature added while developing GitHub: cubeSQL Web Admin: The Post Build Script builds a “Multi Architecture” Docker Image (linux/amd64 & linux/arm64v8) by building the Xojo Web App for BuildTargets Linux x86 64-bit and Linux ARM 64-bit. This allows to support running the Docker Image natively on Macs with both Intel and Apple processors.
• How to use Launch Arguments and Environment Variables for configuration. This allowed us to configure the Environment Variables in our Docker setup to preconfigure the connection data.
• The approach with subclassed WebContainer’s that implement the WebDataSource Interface. The quite generic base class cntDatasourceBase can be configured to:
  • be searchable (Main Window shows/hides the WebSearchField if the subclassed Container defines to (not) be searchable).
  • define which Fields of a RowSet should be displayed (cubeSQL uses special custom commands for administration, so we can’t select distinct columns ourselves, and there’s no paging within these custom commands).
  • define virtual Fields, which will be shown in the WebListbox, but aren’t part of a RowSet. Internally the base class uses a Dictionary Array which gets built from the RowSet, so one could use it with other external DataSources, too.
  • show the Fields in the WebListBox, while allowing each Container to override the default behaviour (see for example the Databases, which use a WebListboxImageRenderer for a virtual field – depending on a couple of Columns in the RowSet an appropriate Status Icon is being displayed).

To connect to this cubeSQL setup with Xojo I have placed the following code in the Opening event of a Label:

Var db As New CubeSQLServer
db.Host = "localhost"
db.UserName = "admin"
db.Password = "admin"
db.Port = 4430

Call db.Connect

Var rs As RowSet = db.SelectSQL("SHOW INFO FOR KEY server_version")
Me.Text = rs.Column("value").StringValue

MariaDB & phpMyAdmin

MariaDB Server is a high performing open source relational database, forked from MySQL.

You’ll find an example setup for Docker Compose here: GitHub: jo-tools/docker – local-mariadb-volumes.

I’m not going to explain much more here about MariaDB (MySQL) or phpMyAdmin here – I think you should figure out easily how to launch the Administration tool and connect to the server when looking at the contents of this docker-compose.yml. But, since it’s a widely used and well-known database server, I wanted to provide a setup for this combo, too.

As a simple test for this setup I have placed the following code in the Opening event of a Label:

Var db As New MySQLCommunityServer
db.Host = "127.0.0.1"
db.UserName = "root"
db.Password = "mariadb"
db.Port = 3306

Call db.Connect

Var rs As RowSet = db.SelectSQL("SELECT version() AS version;")
Me.Text = rs.Column("version").StringValue

For some reason the connection needs an IP Address or a Hostname (and doesn’t work with localhost).

A Word of Caution

The above setups are only intended as a local test setup – don’t use them like this for production. Even on a local developer machine you shouldn’t run the services with these simple initial login credentials, so go ahead and change them.

The purpose is to explain how Docker Compose works, and how it can help developers to easily setup up local environments to work on database applications. And of course these examples might well be a head start to those that haven’t used Docker before.

That’s All Folks!

I hope this brief introduction of how to use Docker and Database servers for and with Xojo has been helpful to some, food for thought to others.

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Popovers

Similar to WebDialogs, popovers give you the opportunity to improve your apps’ UX. They are ephemeral screens where you can place text and controls.

Unlike the WebDialog, which is always centered and prevents the user to interact with other controls, Popovers can be placed on specific controls, where that information matters.

Think about them as enhanced “contextual menus” but, instead of just plain text menus, you can add anything you like. Have you ever dreamed of adding a WebMapViewer into some sort of contextual menu? Now you can!

The API is very simple. Create a container, add some controls and that’s it, really. You will just have to create a new instance of that container and show it as a Popover, specifying the control it should be pointing to.

Let’s say you have a container, called “MyTextFieldContainer”, and you want to display it below a WebLabel called “MyLabel”. Here is the code:

Var c As New MyTextFieldContainer
c.ShowPopover(MyLabel)

By default, it will be shown below the specified control, but if you want to show it in a different place, you can use the new DisplaySides enumeration. As easy as this:

Var c As New TextFieldContainer
c.ShowPopover(MyLabel, WebContainer.DisplaySides.Top)

As you can see, Web Projects’ Popovers are just container instances that you will show dynamically. That gives you the opportunity to raise events, add custom computed properties or implement the Observer interface. If you are already familiar with Containers, you already know how to use Popovers. Learn more about Popovers.

Displaying contextual menus programmatically

Sometimes Popovers could be overkill for the task. If you just want to display a menu with some textual items inside, a contextual menu might be enough.

Imagine you have a WebTextLabel where you want to display the contextual menu whenever the user Presses on it. In its Opening event you could define the ContextualMenu:

Var menu As New WebMenuItem
menu.AddMenuItem("Foo")
menu.AddMenuItem("Bar")
menu.AddMenuItem("Baz")

Me.ContextualMenu = menu

Implement the WebLabel.Pressed event and add this code:

Me.ContextualMenu.PopUp

As easy as that.

New RemoveControl method

WebViews controls, like WebPage and WebContainer, now supports removing controls. This gives you the missing piece to create GUIs programmatically, as AddControl was already supported .

This can be useful when you are presenting a form to your end user with an unknown amount of fields.

For example, your user is filling the profile and you want to support having multiple contact fields. Some users will want to add 1 phone, others 2, and others would prefer to be contacted just by email.

Adding and removing controls dynamically gives you the opportunity to build this kind of features. Instead of adding a fixed amount of contact methods, you can adapt your app to what your user really needs.

Performance and memory usage improvements

We’re landing at my favorite part, improvements that nobody will see… unless you want to share your server monitoring stats, which is cool.

2024r1 comes with less Disk I/O usage. In my own benchmarks, Xojo Web is now able to serve about 1200 requests per second via the WebApplication.HandleURL event. That’s around a nice 20% more, compared to the previous version.

Also, thanks to Jeremie Leroy (one of our Xojo MVPs) and Bruno Fréchette, we’ve managed to identify and fix some memory leaks. In 2024r1, your web application will be doing a better job at cleaning up after processing requests.

Bug fixes

The list of fixes is big, you can inspect the whole list in the 2024r1 Release Notes page.

Web fixes by category:

• Compiler: 1
• IDE: 7
• Framework: 40

18 extra regressions were reported and fixed during the beta period. A huge thank you to everyone taking the time to test our releases and reporting issues before the final release becomes available.

Conclusion

We hope you are as excited as we are for this release. I’m personally looking forward to see what you’re building, please remember to mention us on your favorite social network so we all can see what you’re working on.

In the meantime, we are already working hard preparing our next release, 2024r2. Spoilers: You will love it!

Happy coding!

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

Monkeybread Software and Christian Schmitz have organized an exceptional event in Germany taking place in just 2 months – April 22nd to 27th. Take this opportunity to meet and network with members of the global Xojo Community. Meet Geoff Perlman, Xojo’s Founder & CEO and Xojo Engineers, Javier Menendez and Ricardo Cruz.

This event includes:

• Keynotes from Geoff Perlman and Christian Schmitz
• Educational, Feedback and Q&A Sessions
• Web Lab with Xojo’s Ricardo Cruz
• Performance Lab with MBS’s Christian Schmitz
• Dinners, Networking and Sightseeing

Training, Sessions & Events

6 Day Schedule

Monday          22nd April        Welcome Event
Tuesday         23rd April         Sight Seeing Tour & Dinner
Wednesday    24th April         Training Day & Reception in Hotel
Thursday        25th April         Conference & Dinner at Baggerado
Friday             26th April         Conference & Farewell Dinner
Saturday         27th April         Geyser Tour

Einstein Hotel Am Römerpark

The event will be hosted at the Einstein Hotel Am Römerpark, a modern business and conference hotel with unique ambiance and modern facilities. Located in Andernach across from the river Rhine, the hotel features a garden, lounge, terrace and the Sky Bar & Restaurant.

Visit, Attend & Network

Location: Andernach

Networking is not limited to the event hotel! Enjoy the evenings with other Xojo users at casual get-togethers. Arrive a day or two before the conference or stay over the weekend and schedule time to enjoy the area. Join the group for sightseeing and a Geyser Tour. Andernach has much to offer visitors including the “Runde Turm” (round tower), Mariendom (Cathedral of Mary), the old crane on the Rhine River front, the Mikveh or the well preserved town wall.

Learn everything else you need to know and Register Today at Monkeybread Software.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

XDC London

We held our first international Xojo Developer Conference in London at the end of April. I can’t emphasize enough what an excellent event XDC London was. Sessions ranged from Android hands-on training, to creating a multi-language UI, plus panel discussions about AI and informative talks from Xojo engineers and experts. Read the XDC breakdown to get links to videos and more. We also had quite a few great meals, one questionable pub dining experience and no one got lost in the Underground.

Xojo Android

It’s been years in the making! After a few false starts and dead ends, we are incredibly excited to have delivered Android support for Xojo in August 2023. Because so much of Android is all-new, the Android support is considered Beta, similar to how we introduced Cocoa and 64-bit support years ago. But, even though it is Beta, we have several users who have Xojo-made Android apps in the Play Store and others who have created Xojo Android apps that are being tested by their own users. Android support is improving with each release and we even added Barcode scanning for Android in Xojo 2023r4, debuting it in Android before it appears on other platforms in 2024. You can read all about what’s new in Xojo Android on the Xojo Blog. With iOS and now Android, it’s never been a better time to make mobile apps with Xojo!

New to Xojo, Inc.

In November 2023 we welcomed a new Marketing Manager to Xojo, April Baynes. You can reach out to April if you have an idea for a webinar or video topic. Additionally, we’ve brought on help to polish the Xojo Documentation and Introduction to Xojo Programming textbook. You can look forward to seeing the results of that in the coming months.

Xojo, The Technical Stuff

Xojo itself has also reached some technical achievements….

• Chart control for Desktop and iOS
• Code Editor and Debugger improvements
• Dark mode for Web projects
• PDFViewer control for iOS
• XAML controls for Windows
• Zip/Unzip for Folderitem
• Geofencing and Visits support for iOS
• Big speed improvements for built apps, in the Xojo IDE and Xojo Web

In additional to all that, the Xojo team has kept hard at work squashing hundreds of bugs throughout 2023. We continue to spend two weeks per release cycle working on bugs that do not necessarily meet the regular criteria. If you have a showstopper bug that you cannot work around, please contact us – our team may be able to help you or escalate it. A huge and sincere thank you to everyone who took time to report Issues and help us troubleshoot. Your knowledge and experience is invaluable in making Xojo better.

From all of us at Xojo, Inc. to all of you in the global Xojo community, thank you! May 2024 bring you peace, joy and great coding with Xojo.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Faster HandleURL Responses

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

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

Here are the results, returning plain text:

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

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

Faster Transfer Rates in Windows and Linux

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

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

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

Static Assets Cache Control

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

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

Improved Compile Time

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

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

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

Events Improvements

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

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

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

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

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

New Experimental Option

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

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

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

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

Wrapping Up

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

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

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

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Xojo Cloud is optimized for Xojo applications. It is specifically designed to provide the best possible performance and stability for Xojo web applications. We optimize Xojo Cloud for performance, so your web apps will run smoothly and seamlessly. You can even monitor server stats from within the Xojo IDE.

Xojo Cloud is focused on simplicity and ease of use and requires zero configuration. Designed with the Xojo developer in mind, Xojo Cloud’s Control Panel makes it easy to deploy and manage web applications. Purchase a server, open a web project in Xojo and click Deploy to upload and install to Xojo Cloud. Not just for web apps, Xojo Cloud includes Apple Push Notification server (APNs) support for your iOS apps. Set up SSL, PostrgeSQL, MySQL, SFTP and a SSH Tunnel with a click in the Xojo Cloud Control Panel (the Control Panel itself is a Xojo web app). The administration of a web server is a significant and constant task; Xojo Cloud allows you to leave that behind and focus on your projects.

We take security very seriously. Xojo Cloud offers advanced security features to protect your data from cyberthreats, including a smart firewall, intrusion and hacking detection and Security-Enhanced Linux. Unlike most hosting solutions that provide little to no security, each Xojo Cloud server is built with our state-of-the-art, industrial-strength, multi-tiered security system woven into its very core. 

Additional features and benefits include daily automatic backups, load balancing and support from the Xojo team. With nine global hosting locations, you are able to host your Xojo web applications close to your users, for speed and an ideal overall experience.

In addition to the standard options, Xojo Cloud servers with more RAM, storage and Virtual CPUs are available. Contact customer support for details about personalized plans. 

Whether you are a seasoned Xojo developer or just getting started, Xojo Cloud provides an intuitive and user-friendly hosting solution for Xojo web applications. Today is a good day to start using Xojo Cloud, visit our website to learn more or see the Xojo Store to pick your package and location.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Dark Mode Support and Bootstrap 5

You can now create web applications with Xojo that respects users’ Dark Mode preference with Bootstrap 5.

There is a new WebSession.ColorMode property you can use. It will be set as Auto by default, meaning it will match the user’s OS appearance preference, but it can also be forced to Light or Dark. It can be changed at runtime and per session.

While not everyone likes Dark Mode, some of your end users will appreciate this. Due to medical circumstances, they might actually need it, so please consider adding support even if you don’t like dark interfaces.

If you want to enable Dark Mode in your previous projects, you will have to manually enable the setting in the Shared Build Settings section (which is turned on by default on new projects):

Color Groups can also be used nearly everywhere, and they will be used in the IDE preview when you toggle between Light and Dark Mode:

In order get Dark Mode support ready for Web, we had to upgrade our internal Bootstrap dependency from v4.6.1 to v5.3.0, which is a huge leap by itself. Bootstrap 5 comes with a refreshed color palette, new components, modernized existing controls and bug fixes. Please check our previous Bootstrap 5 is Coming to the Xojo Web Framework blog post.

If your application wasn’t using a custom Bootstrap Theme (bootstrap.min.css), everything should look more or less the same except for the subtle color palette differences and rounder buttons. Bootstrap 4 themes aren’t supported in Bootstrap 5, please replace it with a v5 theme if needed. Not every theme supports Dark Mode, but the one included in Xojo does.

If you are a theme builder, please check the Bootstrap’s Color Modes documentation. You can also find free Bootstrap 5 themes available at Bootswatch.

We also want to send a big thank you to our third party developers for their effort adapting their Open Source and Commercial plugins and controls to Bootstrap 5. You can learn about what they offer at the Xojo Extras Store and in the Open Source Projects page in the Xojo Documentation.

Accessibility

Navigating and using web applications with the keyboard makes everyone’s life easier. In Xojo 2023r2 we’ve upgraded WebPagination and WebBreadcrumb controls, which are composed of more than one focusable item. Your users will be able to properly use the tab key to go through them.

We plan to continue working on improving Accessibility. Please open a new Issue if you find anything that can help you and your end users.

WebListBox

DataTables, the internal dependency we use for bringing your tables to life, has been upgraded from v1.10.20 to v1.13.4. This recent version includes support for Bootstrap 5 and a few bug fixes that some users were facing in their web projects.

You can now disable your WebListBox by setting its Enabled property to False so your users won’t be able to interact with it. And also, if you were missing this feature that’s in the DesktopListBox, you can now add Variant tags to your columns, using the new WebListBox.ColumnTagAt.

Last but not least, this control comes with a visual Inline Editor, like in its Desktop counterpart:

WebChart

Chart.js, the underlying library we use for WebChart, has been upgraded from v2.9.3 to v4.2.1. Again, we’ve done everything we could on our side so you don’t have to do anything.

The only exception is with the WebChart.OverrideOptions event. If you are currently using it, you’ll have to check the library documentation as the internal options JSON has changed.

You can expect the new DesktopChart features to be working on WebChart, like configuring how the lines look like (including the endpoints), background images or prefix and suffixes. Read New Additions to DesktopChart, MobileChart and WebChart to learn more.

Web SDK

If you are using third party controls, you will notice some of them now have a custom icon in the IDE Library. But even more important, they will use less memory at runtime.

Are you developing Open Source or Commercial Web SDK controls? Remember there is a dedicated Web SDK forum where you can ask any questions you may have.

IDE Performance and Improved CSS Support

Bootstrap 5 makes use of the latest CSS features. We took the opportunity to rethink our CSS parser and improve its performance at the same time. As a result, the IDE preview looks even closer to what you see in the browser, and we render everything faster.

Wrapping Up

Over 50 bug fixes and features were included just for Xojo Web in Xojo 2023r2. Please find a full list in the Release Notes. read more about Bootstrap 5 and updates to WebChart on the Xojo Programming Blog. We are looking forward to hearing your thoughts and seeing what you’re building with Xojo! See you in the forum!

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

Both server and frontend will have less memory footprint now. The team has been working on finding and fixing memory leaks, and optimizing how the framework cleans up the controls, when pages aren’t visible anymore.

Paul and Travis made IDE improvements to load projects much faster. If you have a large Web project, you will surely notice the difference.

The WebListBox component got most of the improvements. Visually, you will notice less flickering. Internally, it will make less requests to the web server to display its data. We will continue optimizing its performance release after release. Interacting with this control is now more natural and accessible, as we’ve made it more compatible with the different OSs and devices. And just like WebListBox, almost every other control received one or more bug fixes. Check the Release Notes for a detailed list.

I would like to finish this post with a huge thank you to every user that has helped directly or indirectly creating Issues, attaching a sample project, posting on the Forum and testing the beta releases.

The community is the best feature of Xojo

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

The system brings a lot of improvements and more visibility, but there are some changes. Some users have asked “how do I find the bugs I have reported” or “how do I search for an issue number” and if you haven’t used this system, those may not be obvious.

Here are some tips for using Issues:

When do I use Issues?

Use Issues to let us know you have a bug or feature request for Xojo, the Xojo documentation, our website, or an example project. Discussing these things on the forum can be helpful but in order to officially let us know about a problem, please create a new issue.

For Customer Support, please contact us via email at hello@xojo.com. Contact Customer Support for general questions about licensing, questions about your account, technical support, etc. If you’re not sure, write us, we are here to help and usually respond very quickly.

How do I search for a specific issue?

If you are trying to find an issue by the issue number make sure you put “#” before it. For example, if you’re looking for issue 69360, make sure to type it in the search bar like this:

If you forget to type in the #, your search will not return any results.

To link to a specific issue, use https://www.xojo.com/issue/<issuenumber>.

How do I create an issue?

Click “New Issue” to create an issue. When you start typing in the title field, you’ll see a list of possible matches populate as you are typing which is helpful to see if your issue already exists.

How do I find the issues I have created?

There are many options for searching. If you click inside the search field, you’ll see a pop-up menu with criteria you can choose from like Author, Label, My-Reaction, etc.

To find the issues you created, perform this search using the popup menu: Author = [Your Username]. For example, the search below will find the issues I have created.

You can search for your issues or those created by other users. Keep in mind that Issues uses the same username as the Xojo Forum.

What do I do if my issue already exists?

If you are searching for a problem that you’re experiencing and find that an issue already exists, please add a thumbs up. If you have additional information, you can add a comment by scrolling to the bottom of the issue.

If your information should be kept private please check the checkbox at the bottom: This note should only be visible to Xojo.

How do I bring more attention to an issue?

If there’s an issue you feel needs more attention than others, you can click the thumbs up button to upvote it. Conversely, if you feel there’s an issue that should get less attention, you can downvote it.

Be aware that the more you upvote issues, the less your votes matter. The same is true of downvoting issues though upvoting and downvoting have independent impact. In other words, upvoting several issues doesn’t change the impact you have when you downvote issues and vice-versa.

How do I find the issues I have added a to?

To see what issues you have added a to, search for: My-Reaction = 👍

How do I see the top feature requests from users?

You can search by Popularity using the dropdown menu to the right of the search field to sort your results. It is important to remember that the Popularity list is not our Roadmap.

Note: If you do a search that you like, add a Bookmark to quickly go back to it in the future.

How do I view my recent searches?

Click the icon to the left of the search bar to see a list of your recent searches:

How do I reopen a closed issue?

If you are the original author of an issue you can close and re-open it yourself. You do not have to ask Xojo to do it. If you are not the author and want to re-open it, just leave a comment on the issue to let us know that it still affects you and you’d like it re-opened. Then either Xojo or the original author will re-open it for you.

Does Milestone mean a feature will be coming in that specific milestone?

Just because something has a Milestone listed, that is not a guarantee that it will be fixed or added in that milestone. It means that it is an issue we are considering for that release.

If you want to read more about issues, check out this page in the documentation. Do you have other tips for using Issues? Please share on the Xojo Forum.

First, in order to deploy a web app you’ll need a way to access the remote server using the Terminal (macOS) or through the Command line, also a way to create and/or modify several files, and to copy files from your local computer to the remote server using (S)FTP.

Note: While we are using the “root” user for all the operations to keep the tutorial as short as possible, including files/folders/directories creation/edition and also for launching the web app, you’ll probably want to create a specific user with the proper privileges/group configuration for this. As we all know, you don’t usually want to run anything as the root user!

Though this tutorial is focused on the deployment aspects of a web app, we’ll first create a very simple web app in Xojo. Feel free to use a web app of your own. At the end of this tutorial, you’ll find deployment of more complex web apps can follow the same basic principles.

1. The Web App

This very simple app will display a message when the button is clicked.  Start the Xojo IDE and choose Web from the Project Selector window:

Click on the WebPage1 item displayed in the Navigator to access the webpage Layout Editor.

Next, drag a button from the Library panel and drop it anywhere on the Layout Editor.

With the button still selected, add the Pressed Event Handler and type this line of code in the Code Editor:

MessageBox "Hola Mundo"

The classic “Hello World” en español, this is everything the web app will do.

2. Setting the Deployment Options

Click on the Shared option found under the Build Settings section in the Navigator. Next, enter 9000 as the port under the Build Settings section in the Inspector Panel.

Note: Adding the port is not required at this time because the port can be assigned when running the app once it is deployed to the server.

3. Compile the Web App

Make sure to choose the Linux checkbox in Build Settings. Then, select X86 64 bit from the Build popup menu in the Inspector Panel.

Next, click on the Build button in Xojo’s IDE toolbar. Once the app is compiled, you’ll get a Folder/Directory with the following items inside:

This is the folder you will copy to the server. I’m using the Cyberduck app on macOS but you can choose any method you like.

4. Copying the App Folder to the Server

Make sure to copy the folder with the compiled app to the /var/XojoApps path on the server (you’ll need to create that folder/directory first). Once all the files have been copied, make sure to set 750 as the privileges value for the folder and files (choose the option to apply these recursively to all of them).

5. Installing Nginx

If the server doesn’t have Nginx already installed, install it now. Nginx is a light web server which provides more performance when compared with Apache (that is, it is able to serve more requests per second, among other improvements).

To install Nginx, access the remote server using SSH:

> SSH root@xxx.xxx.xxx.xxx

Once the new session is open, type the following commands to install Nginx:

$ sudo apt update
$ sudo apt install nginx

6. (Really) Basic Firewall Configuration

Let’s tackle the firewall. It will need to accept incoming connections from Nginx. Nginx registers itself as a ufw service during its installation. In order to simplify the deployment example, use the most restrictive option allowing only web traffic from port 80:

$ sudo ufw allow 'Nginx HTTP'

Type the following command to verify the changes:

$ sudo ufw status

The output should be similar to this (in my case access from SSH and 8080 ports are also enabled).

Note: This tutorial does not discuss web security which in the overwhelming majority of cases should be a paramount issue and not ignored. Securing a server is a very complicated process which is why we take care of the for you with Xojo Cloud.

7. Creating a New Nginx “block”

Once Nginx is installed, Ubuntu automatically starts this process, so the web server should be active already. Test this by typing:

$ systemctl status nginx

The output  should be similar to this:

Once the server is running, create a new server block. Think about this block like the virtual hosts on Apache. They will encapsulate the configuration details and will allow hosting of more than one domain on the same server.

Nginx loads these configuration files from the /etc/nginx/sites-available path. Create a new file using the nano editor:

$ sudo nano /etc/nginx/sites-available/XojoDemo

Next type the following block in the resulting new document:

server	{
listen 80;
listen [::]:80;
root /var/XojoApps/XojoDemo;
index index.html index.htm index.nginx-debian.html;

server_name xxx.xxx.xxx.xxx;

location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_pass http://127.0.0.1:9000;
}
}

Replace xxx.xxx.xxx.xxx with your server IP address or the server domain (DNS record, if you have one pointing to it). We are instructing Nginx to redirect the traffic from port 80 to 9000 where our web app will be listening.

Save the file and exit nano. Next, enable the file by creating a link from the file to the sites-enabled directory where Nginx reads the configuration files:

$ sudo ln -s /etc/nginx/sites-available/XojoDemo /etc/nginx/sites-enabled/

Finally, check for syntax errors in the Nginx configuration files:

$ sudo nginx -t

If everything is Ok, then reload Nginx so it reads the configuration files again and applies the changes:

$ sudo systemctl restart nginx

8. Executing the Xojo Web App

It’s time to start our Xojo web app and test the access from the web browser of your choice. Change the current path to the one where you copied the web app. In this example:

$ cd /var/XojoApps/XojoDemo

Next, start the app by issuing the following command:

$ ./XojoDemo --port=9000

Open a new window/tab in the web browser and enter the IP address/web domain pointing to the web server. There is the web app up and running:

Congrats! Now for the harsh truth. This way of executing web apps is not ideal. Because it started from the SSH session on the server, if we exit or interrupt the SSH connection, the web app will exit and won’t be accessible anymore for anyone. This problem also results in a 504 Gateway Time-Out page served by Nginx:

In order to fix this problem, create a Service.  A service will allow the app to run without any intervention, even if there is a server interruption, for example, if the server is restarted or the app crashes.

9. Creating a Service

Type the following in the current SSH session:

$ sudo nano /lib/systemd/XojoDemoApp.service

Next, type the following snippet of text in the new, opened document (make sure to save the changes once you exit nano).

[Service]
Type=simple
Restart=always
RestartSec=3
User=root
ExecStart=/var/XojoApps/XojoDemo/XojoDemo --port=9000
[Install]
WantedBy=multi-user.target

Now that you have exited nano, and with the new service created, activate it with the following commands:

$ sudo systemctl enable /lib/systemd/XojoDemoApp.service
$ sudo systemctl start XojoDemoApp.service

Get the service status by typing the following command:

$ sudo systemctl status XojoDemoApp.service

You should get an output similar to this:

Now, you can be confident that the Xojo web app will be running even if you close the current SSH connection with the remote server and that it will restart even if the remote server is restarted or the app crashes.

If all of this seems more complex than you care to manage, Xojo Cloud is the easy, powerful and secure way to deploy web apps. Xojo does not provide support for configuring your web server for use with Xojo web apps. To read more about deploying Xojo web apps, visit the Xojo Docs Web Deployment Overview and the Web Deployment Details pages.

First, the performance of WAL mode (write-ahead logging) is improved when there are lots of connections all accessing the same database file. This ought to provide noticeable improvements for web apps that use SQLite databases.

If you use full text searching with FTS5, you can now enable trigram indexing to allow search terms to better match within text blocks.

A minor change is that the “substr()” SQL function can now also be called “substring()” for compatibility with SQL Server.

There are a few other performance improvements as well. Visit the SQLite site to read the official release notes.

Find more SQLite tips