That’s why Xojo is still here: relentless adaptation.

Back when Xojo was REALbasic, version 1.0 only supported MacOS 8/9 and the 68000 and PowerPC processors. Since then we have seen countless changes in the computer technology landscape. Classic MacOS, Windows NT, Windows 95, Internet Explorer 6, Early versions of GTK on Linux, diskettes, and spinning hard drives are now ancient technology.

Xojo itself has changed dramatically over time as well. Though the basic idea of it, that you should be able to quickly and easily both learn Xojo and build apps, has not changed. Some code from an example project back then would be recognizable to a Xojo user today. Assigning variables, conditional statements, loops, even many classes like Graphics, FolderItem, TextInputStream, would all look familiar. That said, almost everything else has changed:

• The IDE was originally written in C++. It is now written in Xojo.
• There entire Xojo framework was originally written in C++. Today it’s a big blend of languages including quite a bit of Xojo.
• It originally had a single pass compiler. The entire compilation process has been rewritten. It is a modern, two-pass system that uses LLVM as its backend.
• REALbasic v1 could only produce desktop apps for MacOS 8 and 9 running on 68000 and PowerPC processors. Today, Xojo supports x86 and ARM processors, desktop apps for Linux, MacOS and Windows, mobile apps for Android and iOS and web apps.
• The documentation was originally almost entirely in printed form. It cost $30, weighed 49 ounces (just over 3 lbs.) and we shipped it to you right from our office. Now, the documentation is all online.
• The way users reported bugs and made feature requests has changed several times over the years.
• The community formed in mailing lists, and occasional Xojo events, now exists on our online forum.

And that adaption continues. We improve the frameworks with each release. We have added the ability to build Libraries. We are working on making web apps more responsive. We are continuing our march towards updating the Windows framework to WinUI. We are making changes to the Xojo IDE so that you can use AI tools such as Anthropic’s Claude Code, Google’s Gemini Code Assist, and Open.AI’s Codex, which, coincidentally, was almost the name we chose for what is now Xojo.

Companies survive by adapting, and Xojo, Inc. is no exception. Over the years we’ve changed everything from offices, personnel, and policies. While the team has changed over the years, many members have been with the company a very long time. In the tech industry, the average turnover is 2 to 3 years. Over the last 30 years, our average turnover is 7 years. Counting current team members, however, it’s a whopping 16.6 years! And among the current engineering team, there are 136 person-years of development on Xojo. We started working out of my apartment, then my house and then into an office here in Austin, Texas. Over time, about half of us found we were working from home a lot, so we decided to go entirely remote in 2008. We have changed many of our internal policies to make Xojo a great place to work. Every member of the Xojo team works so well together that it makes coming to work every day genuinely rewarding.

In general, only about 5% of businesses last 30 years. In tech it’s closer to 1%. It’s an honor to be a member of the tech industry’s 1% club!

What drives all of us at Xojo is helping you turn what started as an idea, into reality. We couldn’t have done it without all the dedicated Xojo users. That some of you have been with us for the entire journey, so far, is especially gratifying.

On behalf of the entire team, thank you for making Xojo possible.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Test 1

Var rs As rowset = SQLiteDatabase1.SelectSQL("SELECT invoices.invoiceno, invoices.invoicedate, invoices.invoiceamount, customers.firstname, customers.lastname FROM Invoices JOIN Customers ON invoices.customerid = customers.id")
Results1.RemoveAllRows
Var grandTotal As Integer
Var totalIterations As Integer  = 10
For i As Integer = 1 To totalIterations
  Var start As Integer = System.Microseconds
  For Each row As databaserow In rs
    ListBox1.AddRow(rs.Column("InvoiceNo"), rs.Column("lastname"), rs.Column("firstname"), rs.Column("InvoiceDate"), rs.Column("InvoiceAmount"))
  Next
  Var stop As Integer = System.Microseconds
  Var total As Integer = stop - start
  grandTotal = grandTotal + total
  Results1.AddRow("Test " + i.ToString + ": " + total.ToString)
Next
Var avg As Integer = grandTotal / totalIterations
results1.AddRow("Average: " + avg.ToString)

Test 2

Var rs As rowset = SQLiteDatabase1.SelectSQL("SELECT invoices.invoiceno, invoices.invoicedate, invoices.invoiceamount, customers.firstname, customers.lastname FROM Invoices JOIN Customers ON invoices.customerid = customers.id")
Results2.RemoveAllRows
Var grandTotal As Integer
Var totalIterations As Integer  = 10
For i As Integer = 1 To totalIterations
  Var start As Integer = System.Microseconds
  For Each row As databaserow In rs
    ListBox1.AddRow(rs.Column("InvoiceNo"), rs.Column("lastname"), rs.Column("firstname"), rs.Column("InvoiceDate"), rs.Column("InvoiceAmount"))
    ListBox1.RowTagAt(ListBox1.LastAddedRowIndex) = row
  Next
  Var stop As Integer = System.Microseconds
  Var total As Integer = stop - start
  grandTotal = grandTotal + total
  Results2.AddRow("Test " + i.ToString + ": " + total.ToString)
Next
Var avg As Integer = grandTotal / totalIterations
results2.AddRow("Average: " + avg.ToString)

I assumed the second test would take longer since it’s doing the extra step of assigning the row to the RowTag property. However, when I ran the test, something curious occurred. The second test, rather than taking more time to complete, took less. This made no sense to me. It’s doing more so it should take longer. It’s not logical that asking it to do more would result in the task taking less time. After examining my code, I could not find any issues with it.

I modified the code to run each test 10 times then compute the average of all 10 tests. Depending on the run, the average time for Test 2 was nearly always shorter. Occasionally the average for Test 1 would be shorter than Test 2 but rarely. In fact, on my M4-based MacBook Pro, Test 2’s average was, in most cases, anywhere from 5% to 25% faster than Test 1. Next I tested it on an M1-based MacBook Pro with similar results. Then I tested it on an x86-based PC running Windows 11. This time Test 2 was slightly slower than Test 1 as I had been expecting from the beginning. Last but not least, I tested on Windows 11 running via Parallels on my MacBook Pro, compiling for ARM-64. In this test, Test 2 was indeed faster. I tried running these tests by changing the order (Test 1 then Test 2 followed by Test 2 then Test 1) and by quitting between runs. None of that seemed to matter.

The difference appears to be ARM. It could be the compiler or the CPU. Our Director of Engineering, Travis Hill, suspects that perhaps something like the branch predictor in the CPU is hopping a tiny bit faster because of the extra assignment and thus can better predict the next operation with the For Each loop. That could be. The timing is in microseconds so the difference is so small that for my purposes, it doesn’t matter. However, that it’s faster to do more work in this case is fascinating and unexpected.

In any case, it’s interesting to see code behave in a way that is so counterintuitive. Asking the method to do more, at least on ARM-based machines, caused the method to take less time.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

When you create a Library in Xojo, it’s tailored to the project type you’re working in, whether that is Desktop, Web, Mobile or Console, so everything stays organized and easy to manage. The Library format was designed to support all project types simultaneously; unfortunately, the Xojo IDE was not. The good news is that there are still ways to take advantage of the flexible underlying format. Since Libraries are simply .zip files, you can change the extension to .zip and decompress them to explore their contents. Inside, you’ll find a folder named for the project type you originally created it from, making it easy to understand the structure. Here are two ways to create Libraries that support multiple project types.

Merging Libraries Manually

To manually create a multi-project-type Library, start by building a separate Library for each project type your functionality supports, then change each one’s extension to .zip and decompress it. Choose one decompressed Library to serve as the final version, and copy the project-type folders (Desktop, Web, iOS, Android or Console) from the others into it. When everything is combined, recompress the folder back into a .zip file and change the extension to .xojo_library. You now have a single Library that works across all the project types you included.

Using LibMerge

LibMerge is a utility we created to make it easier to merge Libraries.

1. Download LibMerge for Linux, macOS or Windows. It will be included in the Extras folder in the next major release.
2. Launch LibMerge and then click the Add button to select the Libraries you wish to merge or drag them into the Libraries list in the LibMerge window.
3. On the Info tab, make sure the Version, Copyright and Description values are as you want them for the merged Library. These initial values are loaded from the first Library you add to the list.
4. Click the Save As button to choose a name and location for your merged Library. That’s it!

If you choose two libraries that both already support the same project type, LibMerge will tell you and not load the second Library. Included with LibMerge is the LibMerge Library which you can use to build the merging of Libraries into your own build tools. Check out the included LibMerge API Guide for details. Here is an example:

Try
   Var merge As New LibMerger
   merge.AddLibrary(SpecialFolder.Desktop.Child("MyDesktopLibrary.xojo_library"))
   merge.AddLibrary(SpecialFolder.Desktop.Child("MyWebLibrary.xojo_library"))
   merge.SaveMergedLibrary(SpecialFolder.Desktop.Child("MergedLibrary.xojo_library"))
Catch error as UnsupportedFormatException
   System.Beep
   MessageBox(error.Message)
End Try

Whether you prefer to roll up your sleeves and merge Libraries manually or let LibMerge handle the heavy lifting, Xojo gives you the flexibility to build reusable components that work across all your project types. With a little exploration and the right tools you can streamline your workflow, reduce duplication and keep your projects cleaner and more maintainable. LibMerge makes this process fast and reliable whether you’re merging two Libraries or twenty. Read more about Libraries in the Xojo Documentation.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

macOS 26 and iOS 26

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

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

WinUI

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

Conclusion

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

Apple released macOS 26 and iOS 26 today, the first versions to ship with Apple’s new Liquid Glass look and feel.

The current release of Xojo (2025r2.1) runs smoothly on macOS 26 and can build apps that run on both macOS 26 and iOS 26. However, because 2025r2.1 uses an older version of Apple’s SDKs, many controls in both the IDE and the apps you build will still use the previous look and feel when running on these new macOS and iOS versions.

We’ve been working throughout Apple’s beta cycle to bring full support for Liquid Glass to Xojo. As you might imagine, Apple made a lot of changes to the OSs along the way — changes that affected things like our layout editor, control sizing, and behavior. Some of these changes were still happening very late in the process. Now that macOS 26 and iOS 26 are officially shipping, we finally know what the end result looks like and how it behaves.

Supporting Liquid Glass and the underlying system changes is a big undertaking and we still have more work to do. Since we build Xojo with Xojo, this means updating not only the Xojo framework but also parts of the IDE itself so it looks and behaves correctly on macOS 26 with Liquid Glass. Our goal is to let you use Liquid Glass in both built-in Xojo controls and third-party party plugins as soon as possible. That’s why the next release of Xojo, 2025r3, will be built for macOS 26 and iOS 26, giving your apps the latest look and feel while still allowing them to run on older versions of macOS and iOS. This includes projects still using API 1 windows and controls.

Because of the scope of these changes — along with other big, exciting features in the works — the testing cycle for 2025r3 will be longer than usual. As a result, 2025r3 will likely be our last major release of the year, followed by any needed point releases. The good news is that 2025r3 will pack in everything you’d normally see across two releases, plus more. It’s shaping up to be one of the biggest Xojo releases in recent years, with plenty beyond just Liquid Glass to look forward to. Additionally, the updates for 2025r3 aren’t limited to macOS or iOS — there are improvements and new features coming for all platforms, so every Xojo user benefits.

If you have a current license and would like to get early access, we’d love your help testing 2025r3. Just reach out and we’ll be happy to add you to the beta program. We can’t wait to hear your feedback once testing begins!

If you are a long time Xojo user, you know we have been through a lot of big changes like this. Sometimes we get it all done in a single release and sometimes it takes a few to get to 100%. Regardless, our goal is to make the transition for you a smooth one.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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

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

Graphics vs. WebGraphics

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

Using a Variant

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

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

Var g As Graphics = context

or

Var g As WebGraphics = context

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

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

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

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

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

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

The full DrawBoard method looks like this:

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

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

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

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

Checking Out the Examples

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

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

As Senior Engineer Paul Lefebvre wrote back in 2022, Xojo added the ability to create Code Assistants starting with Xojo 2022r1. Code Assistants are functions that manipulate the code selected in the Code Editor to help with various code editing tasks. Code Assistants are written in XojoScript, but XojoScript has no access to the Xojo Debugger. Fortunately, there’s a simple solution to this problem.

Xojo’s Code Assistant Tester example project makes it easy to test and debug your code before you create your Code Assistant. Go to File > New Project, click on Examples then open the IDE folder to find it. With this example, you can enter the code that would go into your eventual XojoScript that will be your Code Assistant. Because this code is in methods in Xojo itself, you can test it and debug it with the Xojo Debugger.

Here’s a quick video on how to use Code Assistants and the Code Assistant Tester:

If you write some handy Code Assistants, consider sharing them on the Xojo Forum they could be useful to others in the community.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Like 4D, Xojo has a drag and drop user interface builder, a Code Editor, a Debugger and a Compiler as well as a cross-platform framework. While 4D now has an object-oriented language as an option, Xojo has always been object-oriented. The language is a dot syntax not unlike Javascript. You do not have to become an experienced object-oriented programmer to use Xojo. One of its strengths is that you can learn incrementally.

Xojo supports database application development but there are differences between how it and 4D handles that. 4D has its own database engine and query syntax. Xojo supports SQLite, PostgreSQL, MySQL and ODBC for accessing databases. Unsurprisingly it uses SQL as its query syntax. Because 4D is solely designed for database application development, it ties the user interface you create to tables in the database. Xojo does not. 4D’s model prevents you from having to write code to get data from database records in and out of your user interface. While by default Xojo does not provide this, it provides an add-on called DBKit which assists you in connecting to and interacting with databases.

Xojo supports desktop development for Linux, macOS, Windows and Raspberry Pi (Linux on ARM). It supports web development as well and mobile development for iOS and Android. You can also build console apps which can be handy when you need an app with no user interface to run on a server. Xojo uses native controls and compiles to native machine code for x86 and ARM. Whether you come to Xojo to build desktop, web or mobile apps, you’ll find that 95% of what you learn and the code you write will be applicable to all targets. With the exception of iOS (which because of Apple’s requirements must be built from a Mac) you can build your apps from any platform to any platform. Xojo also includes a Remote Debugger which allows you to build from one operating system and run on another. For example, you might do your development on macOS but want to debug on Windows to track down a Windows-specific issue. With the Remote Debugger, this is quite easy.

Xojo is free to use for development. You only purchase a license when you need to deploy. This is a developer license, not a deployment license. That means that you can deploy as many applications as you like to as many users as you like, without any additional cost. Each developer purchases their own license. A Xojo license comes with 12 months of updates. The new Xojo releases available during your license period continue to be available to you even after your license expires. Renewing your license gets you another 12 months of updates. If you only need to deploy cross-platform desktop applications, the Xojo Desktop license is $399USD. Yearly updates are also $399USD. If you wish to build for any platform we support, the Pro license is $799USD. Yearly updates are also $799USD. Compare licenses and find more pricing details at our webstore.

If you’d like to give Xojo a spin, I recommend starting with the QuickStart and then the full tutorial. After that, check out DBKit, the video and its tutorial which will make it easier to build database-oriented applications. These are the desktop tutorials but there are also tutorials for mobile and web application development. Because Xojo is a general, cross-platform development tool rather than one specifically for database applications, what you build with it is truly limited only by your imagination. If you have any further questions, please reach out to us. Our user forum is also filled with experienced and enthusiastic Xojo users that answer and have answered hundreds of questions. And the Xojo Blog has many posts on database development with Xojo.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

On November 12th Thomas Kurtz, the co-inventor (along with John Kemeny who passed in 1992) of the BASIC programming language died at the age of 96. It would be difficult to overstate the impact he had on computing. BASIC made it possible for so many people (myself included) to begin their journey into programming.

In the late 1970s I became interested in learning to code. My father, who was an electrical engineer and coded in Fortran at work, brought home a book that taught the basics of programming. Written and published by Apple, it appeared to only cover 6502 Assembler, the chip that was in the Apple II. Just a few pages in my eyes began to glaze over and I started to wonder if programming was really for me. Fortunately, I flipped the book over to find it was actually two books in one. From the other side it was a book about AppleSoft BASIC. As I looked at the language, it made immediate sense to me. Assembler was too low level and not a great first language but BASIC was ideal for this purpose. I learned enough to get going and my life was forever changed.

Programming has evolved a lot since then but we still design Xojo with the same principle that Thomas and John espoused with their original version of BASIC: that programming should be accessible to anyone with an interest. We have many users whose first experience with programming was with Xojo just as mine was with BASIC. In our own way, Xojo is continuing what Thomas and John began. Today more people have the ability to learn programming than ever before. Thomas and John both were true pioneers that contributed significantly to making that happen.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

If there’s something you need to do in code when the orientation changes, you’re in luck. The MobileScreen class has an OrientationChanged event. When this event fires, that means the user has rotated their device and the orientation has changed. This is where your code would go should you need to respond to an orientation change.

Note: If you need to know when the screen has changed in size, that’s what the Resized event is for (at least on iOS – it’s not yet supported for Android).

What might not be immediately intuitive or obvious is that rotating your device does not automatically mean the orientation has changed. Consider the following example project that displays the Resized and OrientationChanged events in a table when they occur. While this is on iOS, it works the same way (without the Resized event) on Android. The device is starting in portrait mode.

We will focus on just the OrientationChanged events for now. It gets an initial OrientationChanged event. Then the user rotates their phone clockwise enough that the orientation is changed from portrait to landscape.

You can see that another OrientationChanged event has fired as you’d expect. Next the user rotates the phone clockwise again.

Now the phone is upside down. Notice, however, the orientation from the perspective of the OS has not changed. The layout is still in landscape orientation. This is not a bug. The device does not support portrait mode when the device is turned upside down. Thus the layout is still in landscape orientation and thus no OrientationChanged event has fired because there has been no orientation change.

Next the user rotates the phone clockwise yet again.

You might think that an OrientationChanged event would fire, but it doesn’t. Why not? Because as far as the OS is concerned, the layout is still in landscape orientation. It has not changed its orientation. Finally, the user rotates the device clockwise once last time.

This time the orientation has changed from landscape to portrait and thus the OrientationChanged event fired. Given that the initial OrientationChanged event fired when the app launched, out of the four 90 degree clockwise rotations, only two orientation changes occurred and thus only two OrientationChanged events fired.

This is one of those cases where what is initially intuitive turns out to be wrong until you look more closely at what is really going on.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

As an example of how you might use ChatGPT in Xojo, I looked for a way to turn statements into questions. So I ask ChatGPT:

Turn “numerical limits of double in xojo” into a sentence.

ChatGPT’s response is:

What are the numerical limits of the double data type in XOJO?

Getting Started

Before you can run the example to test out the ChatGPTConnection class or use it in your own projects, you’ll need to do three things:

1. Create an account at OpenAI.com. This is free.
2. Add a payment method to your account (to use ChatGPT via an API, you need pay – more on that in a bit).
3. Get an API key. You’ll need to have added a payment method before you can get an API key.

One you have done this, open the ChatGPT Example project, open the ChatGPTConnection class and in the Inspector assign your API key to the APIKey constant. Now you can run the example. The example presents a window where you converse with ChatGPT.

Each window is a separate context. Try choosing File > New Conversation. Referring to questions you asked in another window won’t work because in this example each has its own context.

Using the ChatGPT Classes in Your Project

To use the ChatGPTConnection class in your project, copy both the ChatGPTConnection and the ChatGPTException classes to your project.

To use the ChatGPTConnection class, either drag it onto a window, webpage or mobile screen or create an instance in code. Most of the work is done by a single method: ReplyToPrompt. The syntax for ReplyToPrompt is:

ReplyToPrompt(prompt As String, Optional MaintainContext As Boolean = False) As String

In its simplest form, just pass your prompt and the class will return ChatGPT’s response. For example:

Var gpt As New ChatGPTConnection
Var response As String = gpt.ReplyToPrompt("Where were the 1980 Olympic Games held?")
MessageBox(response)

When you want ChatGPT to consider past requests in the same session, pass True for the MaintainContext parameter. This tells the ChatGPTConnection class to keep a history of all your requests and the responses from ChatGPT which it then sends along with your new request each time you call the ReplyToPrompt method. The amount of text you can send is not unlimited so only set MaintainContext to True when you really do need it to consider previous requests and responses. ChatGPTConnection defaults to GPT 3.5 Turbo which has a maximum limit of 16,385 tokens per context. A token is a number of characters. The conversion is approximately 4 characters per token. Think of a token as a typical word. When you set the MaintainContext property to True, the ChatGPTConnection class monitors your usage of tokens. When it gets to 90% of the allowed maximum for the model you are using, it will start trimming the oldest requests and responses from your history (stored in the ContextHistory property) to avoid you going over the limit.

ChatGPTConnection Class Properties

You don’t need to set any of the properties in the ChatGPTConnection class as they all have useful default values. However, if you want to use a model different from the default (gpt-3.5-turbo), you can set the Model property before calling the ReplyToPrompt method. You can find a list of models here. Models have different limits as to how many tokens you can use so when you change the Model property, make sure to also change the MaximumTokensPerContext property to the appropriate value for the model. The Temperature property indicates how creative ChatGPT will be. Another way of saying this is how much it will hallucinate. Its value range is from 0 (don’t hallucinate at all) to 2 (hallucinate all you want). The default is 0.5. Finally, the TimeOut property is how long ReplyToPrompt will wait for a response. The default is 30 seconds.

If anything goes wrong, the ChatGPTConnection class will raise a ChatGPTException so make sure to put your calls to the ReplyToPrompt method in a Try Catch statement:

Try
   Var gpt As New ChatGPTConnection
   Var response As String = gpt.ReplyToPrompt("Where were the 1980 Olympic Games held?")    MessageBox(response)
Catch e As ChatGPTException
  MessageBox("Error: " + e.Message)
End Try

Pricing for ChatGPT is by millions of tokens. Chat GPT 3.5 is relatively inexpensive so if it gives you the results you want, use it. As of this writing, every 1 million words/tokens you send it will only cost 50 cents in US dollars. Every 1 million words/tokens you get back in response will cost $1.50 USD. If you need higher quality responses, consider Chat GPT 4.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

Remote Debugger

With Xojo, you can. Let’s talk about Xojo’s aptly named Remote Debugger. In the instance above, that particular user can install Xojo’s Remote Debugger app on their computer. You and your users can find the app included in the Extras folder of the Xojo download. After your user installs, launches and sets the Options in the Remote Debugger app, you can connect to that user’s computer by adding a connection to it in the Debugging pane of the Settings dialog box in the Xojo IDE on your computer.

Press the Add button, choose a name, add the user’s IP address and the password they created for the Remote Debugger app. If the user is just barely remote (on your local network for example), the Add dialog that appears will show local Remote Debuggers, making the process even easier. If this is the case, you can click on the user’s machine from the list without having to ask them for the their IP address.

It gets a bit complicated if you and the user are not on the same network. That’s because their router has to be configured to allow the connection to get through to their computer. That can be complex and potentially not allowed by their network administrator. The easiest solution in these cases is to use a service such as ZeroTier or Tailscale that creates a secure, private network which effectively puts you both on the same network making it a breeze to connect. (Both of ZeroTier and Tailscale have a service tier that is free.)

Once you’ve added the remote debug host, you can choose Project > Run Remotely and then choose that host to begin the connection. When you do this, your computer will compile a debug version for the computer and OS running on that remote user’s computer. It will then send that build to their computer and launch it. The app will then connect back to your Xojo IDE’s Debugger! You can then debug just as you normally would. Have the user try various functions as you watch what they are doing using screen sharing of some kind. When it drops in to the Debugger, you can step through the code, look at the values of variables and properties, etc., just as you do when debugging on your local computer. In cases like this, it can take a frustrating, painful debugging experience and make it nearly stress-free. In minutes you’ll be staring at the line of code that just wasn’t expecting the user to do what they did.

Also, the remote computer doesn’t have to actually be remote. For example, the Remote Debugger is handy for debugging on local virtual machines or other computers on your desk. It lets you keep your project where it belongs (where you keep it on your computer) while debugging in an OS running somewhere else.

So the next time you wish you could just debug on another computer or virtual machine, remember Xojo’s Remote Debugger! Watch a 13 minute video on Xojo’s Remote Debugger to learn more.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

1. Drag a DesktopXAMLContainer to a window.
2. Add the Opening event handler.
3. In the Opening event handler, create the XAML string that defines the control you want and concatenate in your localized constant.

Here’s an example of a simple button with a localized constant named Hello used to define the button text:

Me.Content = "<Button Name='Button' Content='" + Hello + "' />"

Notice that you can use single quotes for the the values. Which makes concatenating them via code easier.

If you’re not exactly sure what the right XAML code is, drag out a DesktopXAMLContainer, click on the Pencil icon on it and then choose the control you want and click the OK button. In the Inspector, you can now edit the Content property of your control to see what the XAML code is to create that control. You can then set the Content property in the Opening event (as described above) using that string.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

You can add a subclass of DesktopXAMLContainer to your project then create an instance of it at runtime when your project compiles for Windows. I created an example project that is available now (thanks to the fact that Xojo now loads examples over the Internet). It’s called ChameleonControls and you can find it by going to the Project Chooser, clicking on Examples then going to Platforms > Desktop > Windows > XAMLContainer > ChameleonControls.

The example project explains how it works but essentially you:

1. Add a subclass to your project setting its Super to DesktopXAMLContainer.
2. In its Opening event or the Constructor method, set the Content property to the appropriate XAML to create the control you want. You can get this by dragging a DesktopXAMLContainer to a layout, then clicking the Pencil, choosing the control you want and copying the contents of the Content property from the Inspector.
3. Next you add a property of the type of the subclass you created to the window. In the example, the subclass is called ToggleSwitch (because that’s the type of XAML control it creates) so the property on the window is MyToggleSwitch As ToggleSwitch.
4. Using conditional compilation, in the code of the Opening event of the control you wish to swap out on Windows, you hide the control then create an instance of your subclass, setting it’s Left and Top to the same values as the control on the window.
5. In Build Settings > Windows > Advanced, set the Use WinUI (Experimental) option to ON. When you run, the control on your layout is hidden and the XAML control appears.

Download the example project and check it out.

Got ideas for examples you’d like to see us add or topics for blog posts? Contact us.

1. If you haven’t already downloaded and installed Android Studio, do that now.
2. Launch Android Studio.
3. If you have already created a project in Android Studio, you can open that project. Otherwise, click the New Project button.
4. In the dialog box that is displayed, choose the default project type.
5. Click the Next button then click the Finish button.
6. Once you have a project open, choose Tools > Device Manager. The Device Manager pane appears on the right side of the project window.
7. Click on the Create Device button. The Virtual Device Configuration dialog box appears.
8. Choose the category for the type of emulator you need. Phone is chosen by default.
9. Scroll through the list of devices to find one that suits you. We recommend choosing one that has the Google Play Store icon in the Play Store column.
10. Click the Next button.
11. On the System Image page the appropriate system image for the device you selected should be automatically selected for you. Just make sure the version of Android is at least the minimum version supported by Xojo.
12. Click the Next button.
13. On the final page you can rename the device if you’d like. If you’re going to be creating a lot of Android apps, consider increasing the storage in your emulator by clicking the Show Advanced Settings button and then scrolling the lefthand pane down a bit until you see the Internal Storage field. It defaults to 2048MB so you might want to increase that a bit.
14. Click the Finish button. Your emulator appears in the Device Manager pane.
15. Quit Android Studio and go to Xojo. Android Studio cannot be running while you use emulators in Xojo.

Now you’re ready to use the emulator you created.

In Xojo, open an Android project, in the Navigator click on Android under Build Settings and you’ll see the Android Debugging section. If you have only created one emulator, it will be selected by default. If you’ve created several, they will all be listed.

The first time you use a new emulator it takes Android Studio it takes a bit longer than normal for it to launch. These emulators also sometimes stop working. When that happens, launch Android Studio, open a project or create a new one, go to Tools > Device Manager to display the Device Manager pane, delete the bad emulator and create a new one.

Don’t forget that Xojo supports on-device debugging (Video: Setting Up On-Device Debugging on Your Android Device) as well so if you have an Android phone or tablet, you can run your apps directly on the device which you may find to be a better overall experience for testing and debugging.

Learn more about using Xojo Android in the Android category in the Xojo Programming Blog.

Apple has released the developer documentation for Vision Pro, their recently announced mixed reality headset. So far, it looks promising that iOS apps written in Xojo will just work. Of course, we don’t yet have one of these to use for testing. If we did, we’d be too busy playing with it to write this blog post, however we have tried running some Xojo iOS projects in the Vision Pro Simulator and they work without modification so that’s a very good sign.

RESTy uses the URLConnection class to send a request to a web service and get a result. If the result is text (JSON, for example) it displays in the Response tab. Here, I am calling the Eddie’s Electronics web service to return a list of all the customers by specifying the URL and clicking the Fetch button:

For other data (binary data such as pictures) you can use the Fetch to File button to save the request to a file.

The Authentication tab is used to provide Basic Authentication should the web service require it.

The Request Content tab can be used to provide Content data that the request might need. For example, the Eddie’s Electronics web service also lets you request the details for a specific customer by providing simple JSON containing the customer ID. To try this using RESTy app:

1. Click on the Request Content Tab.
2. To indicate the customer you wish to retrieve, enter the following JSON into the field on that tab: {"ID": 10039}
3. Select POST from the Send Method popup menu.
4. In the URL field, enter: https://eews-demos.xojo.com/GetCustomer
5. Press the Fetch button.

If you have entered everything correctly, will see the data for Caleb Horn in JSON format:

And to see the JSON formatted nicely, click the Format JSON button:

This will let you you explore calling various REST API services. You can explore the source code to see how it uses URLConnection to do so.

To be sure, RESTy is very basic, but you have the source code so you and add features to it and modify it for your own testing needs.

Emojis are available on every operating system and platform that Xojo supports from desktop to mobile to web. Because they are built-in to the OS as characters, they are client-side which means that web applications don’t have to load them from the server as they are already available to the browser from the user’s OS. As characters, they are scalable to any font size. There are also a lot of them. According to Emojipedia (yes, that’s a thing), there are over 3,600 emojis as of September 2021.

Emojis can be especially useful for listboxes in web applications because unlike the DesktopListBox, the WebListBox does not have a PaintCellBackground event that can be used to draw graphics into a cell. Instead, if you can find an emoji that represents what you’d otherwise draw into a cell, you can simply assign it without having to deal with graphics at all. For example, there are a series of emojis that are just boxes in different colors that could be used to indicate the state of something: . The famous web game Wordle uses these when you share your results. With over 3600 available, you can likely find an emoji to represent nearly anything you might need from the common smiling face to the less common umbrella on the ground , banjo or moai from Easter Island.

Again, emojis can be used in any type of application, desktop, mobile or web. Here’s an example of them in a web popup menu:

And here they are in a web list box:

The key thing is to realize that they are individual characters which means they can appear alone or mixed in with other characters. If you need them to be larger, increase the font size. Here’s the lion for example at 60 point size:

Because they are characters, you can copy and paste emojis anywhere you’d use a character, including in your code:

ListBox1.AddRow("Fox 🦊")
ListBox1.AddRow("Lion 🦁")
ListBox1.AddRow("Chipmunk 🐿")

Just remember that emojis are characters, not graphics, so you should treat them as such. Notice in the code above, they are inside the quotes. You could even use them to name a variable:

Var 🌋🥥💰 As String = "Yes, you can do this!"

I’m not sure that’s useful, but it clearly demonstrates how an emoji is a characters like any other.

On Emojipedia you can search for emojis by keyword and copy them to the clipboard. Again because they are simply characters, you can then paste them into a Xojo constant, make them the default value of a property or even paste them into the Code Editor to assign them in code.

Keep emojis in mind the next time you need an image in an application.

Tim is quite familiar with the NetSuite API and created an easy to use, free and open source Xojo class that does the heavy lifting on things like authentication, so that you can focus on sending data back and forth. Check out the video of the webinar and Tim’s blog post about it for more details.

Geoff is the Founder and CEO of Xojo, Inc. He started what became Xojo in 1996 and he has been working to improve it ever since. When he’s not steering the ship at Xojo, he’s keeping the beat for the band he formed in high school and learning Korean.

Rather than continue to check on it constantly, I decided it would save me so much time and trouble if the app could text me when it runs into a problem it can’t manage. Fortunately, this is relatively easy to do. Most carriers allow you to send text messages in the form of an email message. In short, you form an email address from your cell phone number and a special domain your carrier provides. With this email address you then use Xojo’s SMTPSecureSocket class, designed specifically for sending email, and provide the socket information on how to login to your email server (the same info you provide when adding your email account to an email app) and then send a message to the appropriate email address for your carrier so that it will be sent to your phone in the form of a text message. If you’ve never used the SMTPSecureSocket before, check out the example code in the Xojo Documentation.

This isn’t a general purpose solution for sending text messages because the carrier will only allow you to send messages to numbers it manages. But this example is a good and simple solution for monitoring you own apps via text messages. There are paid-services that provide REST APIs for a more general purpose solution. In fact, if that is what you need, here’s an earlier Xojo blog post about sending text messages using Twilio.

Geoff is the Founder and CEO of Xojo, Inc. He started what became Xojo in 1996 and he has been working to improve it ever since. When he’s not steering the ship at Xojo, he’s keeping the beat for the band he formed in high school and learning Korean.

There’s a lot of neat new features coming in iOS 16. The kinds of customizations Apple is adding to the Lock Screen are quite nice both aesthetically and practically. While I’m personally not prone to sending text messages I later regret, being able to edit messages and more importantly unsend them, is going to save many relationships. That you can easily switch between dictation and the keyboard means I will probably use dictation a lot more than I have in the past. I have a friend that uses it constantly and I can’t tell you how many times a second text message arrives to explain the incomprehensible message that had arrived moments earlier. That it now adds punctuation will make me want to use it more as dictating punctuation has always felt awkward to me. It will however likely infuriate my kids who think punctuation in text messages is rude. That ApplePay is going to have integrated order tracking is really nice. I have been using an app for that and sadly quite recently several of the companies it allows you to track have dramatically reduced the functionality of their APIs making the app almost useless. That you will be able to easily share photos amongst family members via an iCloud Shared Photo Library is a feature my family will definitely be using. It’s very cool that you can have it automatically share photos that were taken when family members were close by or when they are in the photo itself. It’s a very nice use of Apple Neural Engine.

That Apple announcing a feature to help people escaping abuse says a lot about what they value and how important privacy is to one’s personal safety. It goes right along with features they have added in the past that allow you to reach into your pocket and dial 911 should you need to do that in secret. I’m big into making my home smarter so I was happy to see the Home app getting a facelift as well as Apple working with other companies on smart home interoperability. I’m also a huge fan of CarPlay and seeing Apple’s vision for it becoming nearly the entire way in which you interact with displays and controls in your car and being able to customize that to your liking was far more than I had ever thought would happen. That future is clearly years away because it requires a lot of cooperation with the automakers but as they adopt it, it will certainly sway my future car purchases.

I wear an Apple Watch and very much care about the quality of my sleep. That they have added the ability to see your REM, core and deep sleep cycles is very cool. I will definitely be wearing my watch to bed more often as a result. They are adding a medication reminder system which I can see as being a benefit. I only take one pill a day so it’s not something I would use but my wife takes several and on her busy days sometimes forgets to take them so it’s a feature she will definitely use.

The M2 was something I was fully expecting and it’s nice to see it incrementally getting better. Apple made it clear that performance per watt is the key metric for them and that makes a lot of sense. We need that kind of metric in many other places in society so that we better understand the impact we are having on each other and our planet.

The surprise feature in macOS Ventura was Stage Manager. it makes it easy to avoid the clutter of having a lot of windows open. I wasn’t expecting it and yet I’m sure I will use it. Like Messages, Mail is getting an unsend feature and lots of other nice improvements especially to search (which has always felt weak to me) but I’ll have to test it to know just how much it has improved. Passkeys is Apple’s name for their implementation of the Fido standard they are collaborating on with Google and Microsoft. It’s designed to get rid of passwords entirely, something of which I will definitely be an early adopter. They really have thought that one through. It will make all of our devices and data far more secure. Being able to use FaceTime with Handoff will be really nice. I’ve been on a FaceTime call and then hung up to call someone back from my Mac so it will be nice to be able to just transfer it from one device to another.

The new MacBook Air is a nice incremental upgrade. If you have an Intel-based MacBook Air, this is a good time to upgrade.

iPadOS 16 is bringing some more desktop-like features to iPad. Things like standard ways for accessing documents, renaming them, collaboration, etc., all make iPad feel a little more like a desktop without it being a desktop. It feels like Apple is striking the right balance. They also previewed a new app called Freeform which is essentially a digital whiteboard that you can use to collaborate with others. Though now that I say that, it seems to not really do it justice given that you can share so many different things in a common space, from text, drawings, photos, video and more. It would be great for brainstorming with a remote team.

Overall, this keynote demonstrated a lot of incremental improvements across the software side of the product line and that’s a good thing. We all want something big, new and flashy but those often come at the cost of a lot fewer incremental improvements. I’m actually quite happy that we weren’t blindsided by something that could potentially change our short term plans here at Xojo. I look forward to using many of the new features they are adding this year.

Lots of big projects (both open and closed source) use it for that purpose. We found it has some really great features. For example, they have simplified the process of entering a new case which almost certainly leads to more people using it. The author of a case can close it themselves and then later reopen it without having to ask someone to do so. You can upvote or downvote any case. I could go on and on. That it’s so full-featured and well-thought out is actually unsurprising upon reflection since that’s Gitlab’s business. Naturally we wanted to have all of those features in our own bug/feature tracking system, Feedback. 

Over time that list grew and grew. We decided that some testing of Issues was in order so I wrote an app (in Xojo of course) to transfer all of the data from Feedback into Issues. There are just over 59,000 cases (since Feedback began more than a decade ago) and as you can imagine, transferring all the data along with all the attached files, was a long process. It took nearly a week running almost non-stop 24/7. The API they provide is extensive and allowed me to represent in Issues every case as it was in Feedback. Having all the cases in Issues helped us to see how well it really works.

After much research, test usage and consideration, maintaining bug base software is not the business we are in. While we are disappointed that our nearly complete web-based version is not what we will be using, we are confident that using Issues instead makes more sense. We are in the business of providing Xojo and anything we can do to devote more resources to that, is an improvement. In this case, a system that already does everything we want and more and is being maintained by others out-weighs having one written in Xojo. We already have hundreds of example projects, a great web-based example (Eddie’s Electronics which we will continue to improve), the Xojo Showcase, the Xojo Cloud control panel as well as many internal web apps, all of which are written in Xojo. The development of each of those has resulted in many improvements to the Xojo Web Framework and will continue to do so in the future. Many of you have created even larger and more sophisticated web apps in Xojo such that we have no shortage of feedback from you on how it can be improved. We continue to be grateful for that. We also develop the Xojo IDE and much of the frameworks in Xojo as well. The engineers at Xojo spend more time in Xojo every day than in anything else.

Our migration to Issues is now complete, so launching the Feedback app or clicking on Feedback in the Xojo toolbar will take you to the new Issues system. You will find all of your cases there and you will be notified when they change. You can begin using the new system to look for existing issues, up or down vote them, add new comments, files, create new issues, etc. It’s also very well-designed to promote conversation about an issue. I think you will find it to be easier to use and at the same time more powerful than Feedback. We have implemented single-sign on so you will be automatically logged in using your Xojo credentials. All of the Feedback case links on the forum are being updated to point to the same case but in Issues. 

Issues is far more transparent than Feedback. The benefit to you is that you’ll see more information about each issue. You can see how many issues have been created. You can see to which member of the Xojo team an issue is assigned. You can see which Xojo release (milestone) it’s assigned to as well. Remember that this is only a best guess. When it comes time to begin pre-release testing, if an issue is not yet closed, it likely will be moved to a later release.

We have always strived to be quite open with the community. While change always comes with some cost, we are convinced that this one is in the long-term best interests of the Xojo community and that in the end is what drives us to do what we do.

With this Xojo Documentation site you’ll find:

• A single help window that includes all pages of the documentation rather than just the Language Reference
• A table of contents is always available on every page, making it easy to navigate
• Class pages have been redesigned to have a top-down view (basic information at the top and more detailed information below), making them easier to use and review
• Dark mode support
• Pages that automatically adjust to smaller screens
• Starting with Xojo 2022r1, documentation for each version of Xojo will be available online
• Documentation that is far easier for Xojo to maintain because it’s designed to be used with version control

In Xojo, this documentation system will be online by default, that means that when you access the documentation from within Xojo, rather than using local files, it will access the online Documentation site. Because of this, new content and fixed issues will be immediately available to you in Xojo and on the Documentation site. As always, each Xojo release will come with a complete set of built-in Documentation to be used when Internet access is slow or unavailable.

This Documentation site is currently available for preview. We are still fixing bugs and it is currently scheduled for release in Xojo 2022r1.

Primarily, we focus on the issues having the greatest impact on the Xojo community. However, that focus is not absolute. The engineering team at Xojo is using Xojo all-day, every day. They will often catch bugs in the early stages of the development of a new feature or as a side effect of fixing some other bug, long before that release gets to pre-release testers. The number of combinations of interactions between various parts of the Xojo frameworks is effectively infinite and no system can test everything. That’s why pre-release testing by actual users is so important. When you look at the bugs that are reported, 95.6% have only one user reporting them. Though we provide, in fact require, users to search Feedback before submitting a case, users often describe the same bug in varying ways resulting in duplicates. Given both the infinite number of interactions and some number of duplicate reports, the fact that overwhelming majority of reports have just one user is understandable. That we focus on the reports that have multiple users is also understandable. And of course there are exceptions, if it’s obvious that a new bug is going to effect a lot of users, we will get to work on it ASAP. In addition, if an engineer is working in a particular part of the IDE or a particular framework, since they have take the time to refamiliarize themselves with that code, they will often look for bugs that have been reported against it. 

Development tools are special because the type of people who use them are more likely to report bugs and are more likely to want to search the list of open cases, get updates about bugs and more. While it’s important to report bugs, and we can’t stress enough how much we appreciate the time and care you take in doing so, even if the bug is fixed, you still have to wait for the release in which it’s fixed. Even our engineers have to wait for bugs fixes just like you do. Still, when you run into a bug, please search Feedback first to see if it’s been reported, perhaps think of a few ways it could have been reported and do a few searches. If you find a match, add yourself to the case. If you don’t, please file a case. If you haven’t found a workaround, ask on the forum or contact us directly and we see what we can do to help.

There is a lot of automated testing that goes on before we put out a pre-release to Testers. And we will continue to add more because automated testing is a terrific and efficient way to test anything that can be automatically tested. We are always on the lookout for ways to improve efficiency in our processes.

1. Web-based Feedback: We have been developing a web-based version of Feedback for some time now. It’s been delayed mostly due to other priorities taking precedence. Nevertheless progress on it continues. We expect it to be available this coming year.
2. Because several case statuses are misunderstood, we are simplifying them. The bottom line is that a case is open until it’s not. Changes in status don’t really mean anything as a case could get resolved the day it was submitted or get stalled for months because we can’t reproduce it. Thus new cases will have the status of Open until we need more information from you (in rare cases) or they are closed. The closed statuses (fixed, implemented, etc.) will remain as they were before.
3. Sometimes cases stagnate with little progress. In the case of bugs, this is often because we can’t reproduce them or we don’t have the information we need. These cases impede all of our efforts to search Feedback. Sometime next year we intend to update the system such that when a case has had no activity in two years, the system will automatically change the status of the case to Archived. If you find an Archived case that is still important to you, please request that we reopen it.

We believe these changes will improve our communication with you about feature requests and bug reports. I know that change can be frustrating. Just know that the reasoning is always to improve. If a change doesn’t ultimately accomplish that, or if we find a better solution, we will consider implementing it. To all of you that use Feedback, we greatly appreciate your efforts. You are helping to contribute to making Xojo better for the entire community.