Code Editor

The Code Editor is one of the most commonly used parts of Xojo, so we are always trying to improve it. One of the problems that been reported with it is that it can use quite a bit of CPU. There was also a report of disk access when typing in the Code Editor. After studying the code, I determined that disk access could have been occurring during code hint lookups (that were searching a SQLite database) while typing, but this problem was no longer occurring with the switch to the new documentation in 2022r1 which uses a much smaller in-memory database.

However, I did notice that the Code Editor was sometimes doing too much work. For one example, the code indenting and folding was updated after every character was typed.

Since indents and folding do not usually need to be updated while you are typing, we changed it so that those things are updated when you pause typing, press return or do specific actions that warrant an immediate update (pasting text, for example). The benefit to this change is that much less CPU is used while typing in the code editor and it is harder to type faster than the code editor can respond.

There were other similar improvements to the mouse movement. Previously the Syntax Help Area would be updated live as the mouse moved around the Code Editor. This was distracting and used a lot of CPU as it looked up what to display. With this release, the Syntax Help Area is only updated when the mouse stops moving. This is far less distracting when moving the mouse around and you should no longer see the CPU spike. A nice benefit of the Code Editor using less CPU is that your laptop battery should last longer when you are coding in Xojo.

Also related to the Syntax Help, sometimes it would not show syntax hints based on where the mouse cursor was and sometimes you had to click to get the hint to appear. A few bugs with that were found and fixed so that you should now have more consistent and accurate information.

Some other Code Editor fixes include:

• The text cursor no longer sometimes remains visible when the Code Editor does not have focus. I found it confusing when that happened.
• Syntax hints are displayed for more keywords, such with looping and conditionals.
• Option-Right-Arrow no longer positions the cursor incorrectly in certain situations.

Syntax Help

It had been a long-standing complaint that the Syntax Help Area only showed the method signature for a single method, which was not all that helpful when it was a method that had multiple overloaded signatures, which is frequent with object-oriented programming.

Travis initially implemented the changes to allow the Syntax Help Area to show multiple method overloads. You may be surprised to learn that this actually required changes to the AutoComplete component.

There were a lot of changes, but they were not too difficult. The trickier part was finding the various permutations and edge cases, which is where I came in. Initially we had the Syntax Help Area expand to show all the overloads, but during pre-release testing we noticed this could cause it to expand to fill the entire code area if you had a lot of overloads (such as with XojoUnit’s Assert() methods). We decided to instead have a max size of 4 lines and use a scrollbar if there were more.

When reviewing this display code I noticed that the Syntax Help Area was always meant to use the same font as the Code Editor, but due to a bug (from 2013 or so) it was unintentionally using the system font. Using the Code Editor font for this makes it much easier to read.

While in this part of the code I also improved the display of the descriptions that appear in the Syntax Help Area (after the member syntax) when they are set on project item members (using the Description field in the Inspector). In addition, Constructor descriptions are now shown.

Thanks

Xojo has been around for over 20 years now and with continued iterative improvements throughout the years has remained a useful and productive tool for thousands of developers making desktop, web and mobile apps. I am honored to be able to work on it and am always in awe of the great things that I see our users create, things that they may not have been able to make using other more complicated tools.

I want to thank everyone for their bug bash submissions and especially those that helped test during the 2022r3 pre-release period. Your well-crafted Issues with sample projects were appreciated! As announced at the Xojo Developer Retreat last month, we are going to continue this with two weeks of bug bashing at the start of each release cycle, which begins around the time a release such as this ships.

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

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

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

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

The community is the best feature of Xojo

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

In addition to the 100 fixed issues, many more issues were reviewed and closed for other reasons. For example, issues were closed because they were caused by errors in the user’s code, they were a problem in the OS, or they were duplicates of another issue, etc.

If an issue you nominated was not fixed, it will still be evaluated at some point. Over the next week the Bug Bash label will be removed from cases and we will be adding a to them so we can keep track of what issues are important to you. Going forward please use the to let us know what issues affect you.

We will be talking more about our long term plan for addressing bugs at the Xojo Developer Retreat.

The Xojo MVPs give us regular feedback on issues affecting the community at large – sometimes that is about a new feature, early testing of a release or more general matters. Recently the MVPs emphasized to us that bugs that don’t affect a lot of users, but can be really annoying to a small group of users, don’t get much attention. We talked about how to best address some of these issues and since we haven’t done a Bug Bash in a while, we decided it was time to do one.

Nominating a Bug for the Bug Bash

Starting now, each user can nominate up to 10 bugs to be fixed during the Bug Bash. You don’t have to nominate them all at once, we will accept nominations through August 31st. To nominate a bug, post this exact language as a comment on the case(s) you wish to nominate in Issues: [BugBash2022Nominee]. Starting in August, our system will add a Bug Bash label to make it easy to find them.

If you find that a case is already nominated with the Bug Bash label, do not add it again. Per usual, if the case affects you, add a “thumbs up” so we have some idea of how many users are affected by a particular bug. Please note that Feature Requests will not be considered for the Bug Bash.

Not every case that is nominated will be fixed. There are a multitude of reasons for this, but each case nominated will be evaluated and we’ll let you know the outcome.

We hope you’ll participate in the Bug Bash. No case is too old, too small or too esoteric! Submit your nominations today!