Firstly, the MVPs work as your advocates, drawing attention to issues that they feel are important to the community. Their passion comes through in all interactions with the Xojo team, from justifiably reminding us of bugs we need to address or features that would be appreciated by many.

Since the MVPs all use Xojo in different ways, this helps to make sure we get a wide variety of feedback. Sometimes we get direct, specific suggestions such as the Set class, which (due to the provided code), we were able to add as a feature to Xojo relatively quickly. Some especially valuable MVP insights regarding stack checking helped us to pinpoint areas where we could make changes to the Xojo framework that resulted in dramatic performance improvements to Xojo itself along with all your projects. MVP tips and testing have also helped us nail down some issues that helped improve debugger stabilization. MVPs have even created a supplemental unit testing suite to help test the Android framework!

Speaking of testing, the MVPs certainly do more than their fair share of testing. They have helped with an enormous amount of testing for many parts of Xojo, most recently including PDF, Barcode, Charts and Android. When they find bugs, MVPs always create thorough, well-explained Issues, usually with sample projects, allowing us to fix things faster for everyone’s benefit. At times MVPs even review your own submitted Issues and may offer suggestions or advice for you to try.

In addition to testing and providing feedback on the product as you see it today, MVPs get to see stuff early, sometimes even before designs or implementations are finalized. This may be in the form of demos or test builds. Their tips, comments and suggestions can help provide direction to how we end up actually implementing a feature or change.

The Xojo documentation is also continuously improved by MVP feedback and suggestions. MVPs were first to see the new documentation site before it was unveiled to everyone and their keen eyes have helped us improve search, sample code and continue to polish things.

From inception to documentation, this group of dedicated Xojo experts has helped us shape Xojo. If you are pleased with what Xojo is today, you should thank a Xojo MVP.

To Anthony, Christian, Gavin, Jeremie, Kem, Martin and Wayne we at Xojo offer a heartfelt “Thank You!” and have made donations on your behalf to several open-source projects that also help make Xojo possible: LLVM Foundation, Bootstrap and Ubuntu.

I’ll outline the way it works here:

• Start typing in the Filter field (1). You can enter a single item or several items names using a comma.
• As you type, the list will display the filtered matches using the default “Begins with” matching criteria. You can change the matching type using the popup menu found at the right of the Filter field (2).
• If you want more control of the items filtered, click on the Edit filter button (3). Here you’ll be able to select the items to filter, clear all or select all of them. The list will be filtered based on that criteria once the dialog is closed.

The combination of the filter criteria and matching type for the current selected stack frame and variable/object will be remembered and automatically applied again when that same object/variable is selected in the Debugger Panel. This also applies when that same project is debugged again, even at different Xojo runs.

As you can see, this debugger filter can be very helpful when there are a lot of objects and variables displayed during the app’s debugging session. No license is required to learn, develop and test your projects in the latest Xojo release! Download Xojo 2023r1 today!

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.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

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.

While pre-release builds require an active license, we recognize that there are some users that, for a variety of reasons, might not have an active license but are nevertheless eager to participate in testing. If this describes you, please reach out to our customer service team to inquire about joining our pre-release testing program. Because pre-releases are made available via the Xojo Forum, to participate you must be a member with forum access enabled in your Xojo account settings.

I’d like to give special thanks to MVP Anthony Cyphers who spent over an hour on the phone with me discussing this issue.

With Apple’s announcements at WWDC 2018 and the introduction of dark mode it was time to revisit our graphics and the overall appearance of the IDE again. Here are some things which contribute to the changes that have been made and ones that you will see in the coming months.

Dropping macOS 10.9

Xojo 2018r3 drops support for macOS 10.9 and as the last version which had the skeuomorphic design elements all of our supported OS’s now have the flatter modern design. It’s not that this has held anything up per se, but it’s a good reminder that “it’s time”. 

To that end, we have taken that opportunity to remove some of the graphics that make the IDE look out of place and doing so subtly lowers the memory footprint and accelerates drawing of the IDE itself across all platforms. We’re also using a variation of Apple’s image templates which has somewhat reduced the on-disk footprint of the IDE itself.

macOS Dark Mode

Apple’s addition of a darker variant of the visual “Aqua” theme in macOS means that we needed to do an audit and update of several of our base framework controls so that your apps would render correctly as well as ours. 

Events

While it probably won’t be used very often (how often does one change themes while running a piece of software, besides the novelty of seeing it happen), we added an event to the App class named AppearanceChanged to notify you when the user changes from light to dark or changes their accent color. This is a good place to clear any graphic or color caches which contain theme specific UI graphics. 

Methods

There is also a new global method called IsDarkMode(Boolean) which will return True if your app is running with the Dark Mode theme on macOS 10.14 or higher. If your app is running on 10.13 or lower or in light mode on 10.14, IsDarkMode will return False.

Build Settings

Enabling Dark Mode in your apps is as easy as flipping a switch in the Shared Build Settings. Unfortunately, because Apple made the assumption that most apps would “just work” versions of your apps compiled with older versions of Xojo will either need to be recompiled with Xojo 2018r3 or you’ll need to push out a new version with a plist entry to prevent macOS 10.14 from showing your app dark in Dark Mode. 

Testing

When testing apps for use with Mojave’s dark mode, I seriously suggest that you test on a system that allows you to see the translucency effects of dark mode. Virtual Machines are usually really handy for testing, but in this case, Parallels Desktop 14, VirtualBox 5.2 and VMWare Fusion 11 do not show the subtleties of dark mode.

Colors

One of our goals at Xojo is to remove some of the headaches involved with the minutiae of each OS that you deploy for and to that end, we wanted to make drawing custom controls easier too. What this means is that the built-in global colors are largely theme aware now and will change depending on whether your app is running in light or dark mode on macOS. This affects things like TextColor, FillColor, FrameColor, HighlightColor, etc, so if you use those methods when drawing in pictures and canvases, you will want to audit that code. If you want a specific color, you should use a color constant. For instance, use &c000000 if you want black because TextColor will now return white in Dark Mode. 

In terms of the framework controls themselves, we are taking this opportunity to make some changes to make your apps appear better in the macOS 10.10+ ecosystem. Ever notice that a Label control and the text portion of a CheckBox or RadioButton control are not exactly the same color? Going forward, the default colors of controls which should automatically change between Light and Dark modes will do that. So if you have a Label using the default color of &c00000000 (Black with Transparency = 0), the color that is actually used is what Apple calls labelColor. It’s still black, but is a tiny bit translucent. TextFields and TextAreas will automatically change text, placeholder, selection and background colors to match the Apple prescribed colors for automatic Light/Dark compatibly. We think you’ll find that building your apps with 2018r3 will largely make them just behave and appear the way you expected them to.

IMPORTANT NOTE: These color and framework changes affect how your apps draw on all versions of macOS, so make sure you try them out on your 10.10 through 10.14 VMs before shipping!

Eating our own dog food

One thing we hear from users every so often is the desire for Xojo to use our own products for building apps. As most of you know the IDE itself is written in Xojo, but we also have several other apps (big and small) that are written in Xojo.

• Feedback – Our bug reporting system
• Xorders – Our internal order system
• Lingua – The Xojo localization app
• Remote Debugger – The remote debugger stubs for desktop and console

While the 2018r3 cycle was in progress, all four of these projects got updated for Mojave’s Dark Mode and definitely helped us find framework rendering bugs early on in the pre-release process.

What about Windows and Linux?

The TL;DR version is that we’re still looking into it. 

Currently there are several different ways to change Windows 7, 8 and 10 to use a dark interface, not all of which are compatible with the Xojo Framework controls and the Windows 10 2018 Fall Update promised yet another way but that ended up only being for UWP. We are looking into which method gets you the most “bang for the buck” so to speak. 

For example, it would not be desirable to send hundreds of emails to all the entries in a database simply to test one of the workflow steps or to verify that emails are being delivered as expected. It would be a lot simpler, and less disruptive to those using your app, to test using a few email addresses that are under your control.

So let’s establish a mechanism that allows us tell our apps when to run in a “simulated” mode vs. a “real” mode for all or some of the components that we need to test along the development cycle.

In fact, the way we can implement this is very simple and is based in the definition of a Boolean property in every class (let’s call it Simulation) that we can make visible under the Inspector Panel using the Inspector Behavior feature. Doing this, we can also change it when we drag and drop the class on the Window Layout tray in order to create an implicit instance.

In association with the property itself, we will implement every public method that will be called from the consumer (other component or code of the app) as usual, with the only difference that we will add two additional private methods for every public method we want to run in both modes: simulated and real. For example, let’s say we have a class that returns a Dictionary array with data from a database. We create a public method for the class, called GetData, but when we just need to test other components it provides some fake data instead of connecting and retrieving a bunch of real data from the remote database. In this case we could define the following methods for the class:

• GetData() As Dictionary(). Public Method, part of the visible interface for the rest of the app.
• GetRealData As Dictionary(). Private Method, called if the Simulation property is set to False.
• GetSimulationData As Dictionary(). Private Method, called when the Simulation property is set to True.

Then, the real code for our public method will be simply this:

Return if(Simulation = True and DebugBuild = True, GetSimulationData, GetRealData)

Simple, isn’t it? With this you will have the maximum flexibility to choose the functionality you want to test using real or simulated data: all, none, part of them … even when you deploy the compiled project it will work always with real data.

Javier Rodri­guez has been the Xojo Spanish Evangelist since 2008, he’s also a Developer, Consultant and Trainer who has be using Xojo since 1998. He manages AprendeXojo.com and is the developer behind the GuancheMOS plug-in for Xojo Developers, Markdown Parser for Xojo, HTMLColorizer for Xojo and the Snippery app, among others

*Read this post in Spanish

First you’ll need Virtual Machine software. I prefer VMware Fusion, but the free VirtualBox can be used instead. You can download VirtualBox from here:

https://www.virtualbox.org

When VirtualBox is installed, you can head on over to the Microsoft site to get a test copy of Windows pre-configured for VirtualBox:

https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

Microsoft provides versions of Windows 7, 8.1 and 10 that you can use for testing purposes. Simply download the ones you want and add them to VirtualBox.

You can install the Xojo Remote Debugger and use these test versions to test your Xojo apps for Windows. Or you can use these to run Windows-specific web browsers for testing your web apps. Keep in mind that these Windows VMs expire after 90 days, so you’ll have to re-download periodically.