Year of Code – Xojo Programming Blog

Year of Code 2025: November Project – PDF Postcard Generator

Gabriel Ludosanu — Mon, 10 Nov 2025 22:32:24 +0000

For November’s Xojo Year of Code 2025, I’ve created a fun and practical project: a PDF Postcard Generator. This desktop application allows you to easily design personalized holiday postcards by combining a chosen image with a custom message, then exporting it as a ready-to-share PDF. It’s a fantastic way to see Xojo’s capabilities in handling graphics, file operations, and PDF creation, all within a simple, intuitive interface.

What this project includes

A DesktopWindow (wMain) that provides a clean user interface for selecting an image, inputting your message, and generating the final PDF postcard.
Intelligent image handling that supports common formats like JPG, PNG, and GIF. The application automatically crops your selected image to a perfect 4:6 aspect ratio, ensuring it fits the postcard layout beautifully.
Robust PDF generation, leveraging Xojo’s PDFDocument and Graphics classes to embed images and render styled text effectively onto the document.
Customizable message rendering, which includes a subtle drop shadow effect for improved readability and a polished look against your background image.
Automated saving of the generated PDF postcard to your desktop, complete with a unique, timestamped filename, and immediate opening of the file in your system’s default viewer for quick review.

Download

You can download the entire Xojo project from GitHub.

This project illustrates Xojo’s robust capabilities for handling graphics and generating PDFs, demonstrating how straightforward it is to create functional and creative desktop applications. We encourage you to use this postcard generator as a springboard for your own ideas. Perhaps you could expand it by adding features like custom fonts, multiple message fields, or even integration with a data source for personalized bulk postcards. Or, consider how Xojo’s PDF features could power entirely new applications for reporting, invoicing, or custom document creation. We’d love to see what you build!

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

Year of Code Project

How to Play:

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

The Prizes:

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

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

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

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

What this project includes

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

How to use

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

Download

You can download the entire Xojo project from GitHub

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

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

Year of Code Project

How to Play:

The Prizes:

Year of Code 2025: September Project, Games

Paul Lefebvre — Mon, 08 Sep 2025 17:57:38 +0000

I’m a bit of a retro computing and gaming guy and I enjoy making versions of retro games using Xojo. Although Xojo is not really designed for making games, its Canvas class works well for many kinds of simple games. That means our theme for the Year of Code for September is Games!

One of the first games I made using Xojo was a clone of Atari Tank (based on the version included with the Combat Atari 2600 cartridge).

The core of Tank served as the basis for the XojoWars game contest, where it was re-imagined as a space battle.

Tank is a rather simple game and really needs to be two-players, which is why I added the ability for two people to play it over the network using UDPSocket. This version, which I called NetTank, is available on GitLab.

On the mobile side, I’ve made a 2048 sliding-tiles game and Turtle, which I suppose is kind of an infinite version of Frogger.

However, I’ve had the most fun making clones of Asteroids and Space Invaders. I wrote some about Invaders in xDev Magazine last year, but at some point I’ll get it enhanced enough to share in a blog post.

With that lengthy pre-amble I can now share my game for this month’s project, which is a clone of Asteroids that I uncreatively call Space Rocks. Although an older version of this game has been included with the Xojo examples for several years, this is an updated version with some new features:

Smaller ship to better match proportions of the rocks.
Improved ‘heartbeat’ sound.
High Score is saved and restored.
Level increases as you clear all the rocks, which adds even more rocks that also move faster.
Command or Shift key now work for firing missiles.

Yes, 14340 is my high score. So far. I dare you to beat it!

The full project is on GitHub: https://github.com/paullefebvre/SpaceRocks

Keep in mind that you don’t have to make an arcade-style game. Strategy and turn-based games are a lot of fun and also great candidates for Xojo. For reference, take a look at the web-based Cosmic Trader game that Ricardo made last year. A platform-style or maze game might also be interesting. I can’t wait to see (and play) what you make!

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

Year of Code Project

How to Play:

The Prizes:

Year of Code 2025: July Project, Charting

Javier Menendez — Thu, 10 Jul 2025 18:32:31 +0000

July’s Year of Code theme is charting. Charting uses the DesktopChart, WebChart or MobileChart controls to make your data stand out with visualizations like Bar, Bubble, Pie, Scatter charts and more.

For this project, I created a small iPhone app to track my expenses – something I personally needed. While it’s designed for tracking holiday and travel spending, it works just as well for managing general monthly expenses.

Far from perfect, but useful for the described scenarios, this iPhone app lets the user set a trip location, add a description and even define a budget. That way, they can check in at any time to see how things are going during a trip or when tracking general monthly expenses. (It doesn’t make much sense to offer this kind of app for iPad.)

When it comes to entering new expenses, I wanted to keep it as simple as possible with minimal input and just a few taps. So, aside from entering the amount and the place where the expense occurred, the app automatically captures the geolocation. This helps me better remember places like restaurants, gas stations or points of interest I might want to stop at or visit again when traveling the same route.

When tracking monthly expenses, the app lets you duplicate existing entries so details like the expense location remain the same, and you only need to enter the new amount. This is especially handy if you tend to refuel at the same gas station or do your weekly grocery shopping at the same store.

So, what about charts? Honestly, this area has plenty of room for improvement and could eventually include a wide range of stats and visualizations. But for this initial release, I kept it simple to meet my own needs. In addition to the basic ‘Total Budget vs. Current Expenses’ stats, the app includes a Pie chart that breaks down spending by category.

Of course, you can download the full source code here and adapt or improve it so it suits your own needs.

Want to give it a try? The iOS app is available for free on the App Store: https://apple.co/3EGL33r

VoyageExpenses is built entirely with Xojo. It’s 100% Xojo code, with only two small exceptions where Declares were needed. It was published to the App Store using the Publish feature introduced in Xojo 2025r1.

Visit the Xojo Docs to learn more about using charts in Xojo. Visual elements like charts can make the data in your apps more memorable and impactful. We’ve written extensively on charting throughout the Xojo Blog.

Year of Code Project

How to Play:

The Prizes:

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

Year of Code 2025: June Project, Cross-Platform Code Class

Gabriel Ludosanu — Tue, 10 Jun 2025 18:00:00 +0000

June’s Year of Code theme is about writing code that works in any type of Xojo project. To demonstrate Xojo’s powerful multi-platform capabilities, this month I’m sharing a practical example: a single data loader and search class you can use—without modification—on Linux, Mac, Windows, Web, Console, iOS, Android or Raspberry Pi!

Introducing `dataClass`: Universal Data Fetching for Xojo

Do you ever wish you could just grab some remote JSON data, search through it, and use it in your app, no matter what kind of project you’re building? That’s exactly what this little, pure-Xojo dataClass allows!

Here’s what it does:

Loads a list of posts from a web API (using standard URLConnection and Xojo’s built-in JSONItem).
Lets you search by any term within the post’s title or body – case-insensitive.
Works unchanged in all Xojo project types – all of them!

Why is This Cool?

By using only built-in classes and avoiding platform-specific quirks, you can build business logic and utility classes that drop straight into your app, whatever the deployment target.

The Complete Source Code

You can copy the full dataClass source from this GitHub repository.

What Will You Build?

Have a favorite cross-platform Xojo technique, class or code module? Show us your own! Share in this month’s Year of Code forum thread.

Stay tuned for more Year of Code 2025 examples, and happy coding!

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

Year of Code Project

How to Play:

The Prizes:

Year of Code 2025: May Project, Mobile Apps

Paul Lefebvre — Wed, 07 May 2025 16:00:00 +0000

One of the most common things I love to use my phone for is sharing pictures of my pets with others. We have two cats and a dog: Shawmut, Christofur and Lucy. To be honest, I’m not much a cat person as I find that cats are almost all Richards, constantly causing and getting into trouble. I’m 100% a dog person.

But even though I have my own pets, I do love looking at pet pictures. It’s a simple pleasure, but there’s not much that I find more calming.

Years ago I made a Xojo app (CatsUp) that displayed random cat pictures and it was a lot of fun. And one thing that Xojo excels at is making it fun to create software! That’s what the Year of Code is all about, after all.

Speaking of that, here is the Year of Code topic for May: Mobile Apps.

You can already find CatsUp for iOS and Android included in the Xojo examples, but why stop at just cats? Being a dog guy, I want to see some dogs. All the dogs.

Since I’m not here to start a cats vs. dogs war, I thought, why not both? It turns out I’m not the only one that thinks this as there are actually public web services that serve up pictures of cats and dogs. Web services and mobile apps go together like peanuts butter and chocolate.

The web service for cats that I’ve previously used is called TheCatAPI and is available here: https://thecatapi.com

There is an equivalent dog one called, unsurprisingly, TheDogAPI: https://www.thedogapi.com

For my mobile app this month, I’ve created an all-new app that can show pictures of cats, dogs or both! I call it Pawz.

Pawz app icon

Actually, it’s two apps since I made versions for iOS and Android. Here’s a look:

Pawz on iOS

Pawz on Android

Although they are separate projects, both use basically the same code. In fact there is only about 50 lines of code in each project! The UI itself is just a big ImageViewer that is used to show the picture and several toolbar buttons.

There are three buttons to request a cat picture, dog picture or a surprise picture that could be either. There is also an extra button that lets you share the picture, if you really like it.

You can find the source for the iOS and Android versions of Pawz on GitHub here:

https://github.com/paullefebvre/pawz

Year of Code is all about having some fun making an app. As you can see with Pawz, it doesn’t have to be anything extravagant. Even fun apps can be made quickly with very little code!

I can’t wait to see what great mobile apps you all create this month. Share your creations in the Forum topic.

One More Thing

Although phones and tablets are what we usually think of when talking about Mobile Apps, you know what else is rather mobile? A vehicle! And it just so happens that many vehicle manufacturers, such as Cadillac, Chevy, Ford, Honda, Polestar, Renault and Volvo are now using Android to run their infotainment systems. Technically it’s Android Automotive OS (AAOS), but it is very similar to regular Android.

Because Xojo builds standard Android Runtime (ART) apps, Xojo Android apps also work on Android Automotive OS as a “parked app”. You can test with this by using Android Studio to install an Android Automotive VM for the Emulator. Once you’ve added that you can run your Xojo Android projects on it just like any other device. Pawz works fine in an AAOS Emulator.

Why do I bring this up? No reason, although I believe Xojo 2025 Release 2 pre-release testing might be starting soon…

Year of Code Project

How to Play:

The Prizes:

Year of Code 2025: April Project, User Interface

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

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

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

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

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

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

Here’s a glimpse of the revamped ToDo app:

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

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

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

Year of Code Project

How to Play:

The Prizes:

Year of Code 2025: March Project, Web Apps

Gabriel Ludosanu — Wed, 05 Mar 2025 15:04:00 +0000

March’s topic is Web Apps and I’m excited to introduce my project: Quiziverse, a complete quiz and trivia web application.

Quiziverse is designed to engage users with time-limited questions across various categories, making it a fun and interactive way to test knowledge. The application leverages a SQLite database as the backend for all data storage.

Here are some of the key features of Quiziverse:

Admin Area: The app includes a secure admin area, allowing administrators to manage categories and questions easily. Admins can add, edit, or delete questions and categories to keep the trivia fresh and exciting.
Scoreboard: A dynamic scoreboard keeps track of player scores in real-time, fostering a competitive spirit among users. Players can see how they stack up against others, adding an element of fun to the experience.
Time-Limited Questions: Each question comes with a timer, challenging players to think quickly and answer before time runs out. This feature adds to the intensity of the game and keeps players on their toes.
Import JSON Files: To make it easy for admins to add new content, Quiziverse includes a function to import JSON files containing new categories and questions. This feature simplifies content management and allows for quick updates.
Mobile Optimized Design: Understanding the importance of accessibility, Quiziverse is designed to be mobile-friendly. Players can join the trivia challenge from their smartphones or tablets for a seamless experience.

Here’s a sneak peek of the Quiziverse interface:

You can find the complete source code for Quiziverse on GitHub, along with detailed documentation to help you get started.

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

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

Year of Code Project

How to Play:

The Prizes:

Build a Xojo Plugin with GitHub Actions

Jürg Otter — Tue, 25 Feb 2025 22:30:00 +0000

As part of Xojo’s 2025 Year of Code initiative, February’s theme is databases—a perfect fit for my recent work on the Open Source CubeSQLPlugin. This article shares insights into automating its build process with GitHub Actions Workflows.

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.

Year of Code 2025: February Project, Database Apps

Paul Lefebvre — Tue, 11 Feb 2025 16:48:26 +0000

February’s Year of Code 2025 topic is Databases and my project is a SQLite object-relation mapping library that I call Storm.

I first created Storm in 2008 when I was working on consulting projects as a way to more rapidly create database apps for clients. It has been updated over the years and the latest version is available on GitHub:

Storm

An ORM lets you write code like this to set database column values and save them:

Var dodgers As New Team
dodgers.Name = "LA Dodgers"
dodgers.Coach = "Dave Roberts"
dodgers.Save

Team is a table in the database with a corresponding class in Xojo that inherits from Storm.DBObject.

The included demo projects shows how you can implement a simple UI for a database with Team and Player tables.

The docs for Storm are contained within its Github repository wiki.

In addition to accessing the full repository on GitHub, you can also download Storm as a ZIP.

I’ve created a forum topic for you to start sharing your Year of Code projects and I’ll also be sure to include this one as well. Remember, participants can win a $100 to use in the Xojo Store!

Year of Code Project

How to Play:

The Prizes:

Year of Code 2025: January Project, Desktop Apps

Paul Lefebvre — Wed, 15 Jan 2025 19:26:16 +0000

January’s Year of Code 2025 topic is Desktop apps and my project is XojoText.

XojoText is a simple text editor that lets you edit multiple files in one window with a list of files in the left sidebar. You can create new blank documents, documents from a selection in another document or from the clipboard.

It is based on the XojoText example that is included with Xojo, but enhanced in these ways:

Word, character, line counts shown at bottom of editing area.
Recent Items menu.
Window menu.
Saves window position.
Prompts to sae changes.
Contextual menu on files in the sidebar.
Click “x” to close files in the sidebar.

Suggestions for improvements and things to add:

Find/Replace capability.
Printing.
PDF generation.

I’ve created a forum topic for you to start sharing your Year of Code projects and I’ll also be sure to include this one as well.

You can download the XojoText project from GitHub here: https://github.com/paullefebvre/XojoText

Year of Code Project

How to Play:

The Prizes:

Year of Code 2025: Kickoff

Paul Lefebvre — Thu, 09 Jan 2025 16:30:00 +0000

Xojo is kicking off 2025 with something for everyone in the Xojo community, an event that will help new users grow their Xojo coding skills and existing users polish theirs. Back in 2018, we did a “Summer of Code” contest that challenged people to create one project a week through the summer. This was a lot of fun and many interesting apps were made that summer. For 2025, we have expanded that idea out to the entire year! However, instead of one app a week, we will make one app a month from January to November 2025. In December we will give away a grand prize!

The Idea

Early each month we will share a blog post that introduces an app “theme” and recaps the prior month. A week or so later, we will create a Forum topic and post an example project created by one of the Xojo team. To participate in the Year of Code, make a Xojo project that that demonstrates the theme in some way, share it on GitHub to make it easily accessible to everyone and then add a post about it (with your GitHub link) to the Forum topic.

If you have not used GitHub before, here is a blog post on how to share a Xojo project on GitHub.

Ideally, these will be small, focused apps that can be made in a few days. The idea is to have fun creating something that others might learn from. But I guarantee you’ll learn something as well. After all, the best way to get better at coding is to always be coding.

How To Participate

Each month Xojo will announce a new theme and share an example project. Share your own projects in the Xojo Forum thread for that month via GitHub, preferably. Projects with code shared at other sites can be eligible as long as the code is accessible to everyone. Learn how to use Xojo and GitHub.

The Prizes

And yes, there will be prizes for those that participate. Each month all participants (everyone who shares a project that month) will be entered for a chance to win a monthly prize of $100 at the Xojo Store plus a 25% off coupon for GraffitiSuite.¹ The $100 can be applied to any Xojo license purchase or Extras Store item. At the end of 2025, all participants from the year will be entered to win the grand prize of a Xojo Pro license, $250 cash and a free year of GraffitiSuite. The more months in which you participate throughout the year, the more chances you’ll have to win the grand prize.

January’s Theme

Now that it is January (Happy New Year, everyone), the 2025 Year of Code kicks off with this theme: Desktop apps. People have used Xojo to make wonderful desktop apps since its inception in 1998 so this is an ideal first theme that is broad enough to allow anyone to participate. Look for a post next week announcing this months’ project details. Once it is posted, I will start a forum topic for others to share GitHub links to their projects and apps. In early February we will do a blog post that highlights what people made this month and introduce February’s theme.

I hope you will join us for the 2025 Year of Code and I look forward to seeing what you make with Xojo!

#2025YearOfCode

Monthly winners are excluded from future monthly prizes but each monthly participant earns an additional entry into the grand prize drawing. ︎

Year of Code Project

How to Play:

The Prizes:

Year of Code – Xojo Programming Blog

Year of Code 2025: November Project – PDF Postcard Generator

What this project includes

Download

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

What this project includes

How to use

Download

Year of Code 2025: September Project, Games

Year of Code 2025: July Project, Charting

Year of Code 2025: June Project, Cross-Platform Code Class

Introducing dataClass: Universal Data Fetching for Xojo

Why is This Cool?

The Complete Source Code

What Will You Build?

Year of Code 2025: May Project, Mobile Apps

One More Thing

Year of Code 2025: April Project, User Interface

Year of Code 2025: March Project, Web Apps

Build a Xojo Plugin with GitHub Actions

Write a Xojo Plugin

Build a Xojo Plugin

Example: CubeSQLPlugin

Build for all Platforms and Architectures

macOS

Linux

Windows

How to Build your Xojo Plugin

How to Transition from Manual to Automated

A Fun Fact

That’s All Folks!

Year of Code 2025: February Project, Database Apps

Year of Code 2025: January Project, Desktop Apps

Year of Code 2025: Kickoff

The Idea

How To Participate

The Prizes

January’s Theme

Introducing `dataClass`: Universal Data Fetching for Xojo