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. 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.

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

Xojo Web is an excellent way to expose the features of your electronics projects without having to attach any screen to them. It’s never been easier to build a Web GUI for your smart clocks, drones, POS, domotics, robots or just some automation services. Thinking about building a solar powered server to automate your tweets? Why not!

If you prefer, you can just expose a Web API instead that can be remotely consumed from another device.

What Raspberry Pi boards support ARM 64-bit Linux OS?

• Raspberry Pi Zero 2
• Raspberry Pi 3
• Raspberry Pi 4
• Raspberry Pi 400

Preparing your Raspberry Pi

The easiest way to get your operating system ready is by using the Raspberry Pi Imager.

At the moment of writing this article, it selects the 32-bit flavor by default. If you have one of the supported boards, go ahead and try Raspberry Pi OS (64-bit) or Raspberry Pi OS Lite (64-bit). The later won’t include any desktop environment, you’ll have to access by SSH.

Select your SD Card storage and press on Write. Optionally, if you want to set a hostname for your board, enable SSH, or even configure your Wifi, press on the gears icon.

In just a few minutes you will have a ready to boot SD card for your Raspberry Pi.

Remotely debugging your projects

This is one of my favorite features of Xojo.

In your Xojo installation Extras folder, you will find a “Remote Debugger Console” and “Remote Debugger Desktop”, that also works for your Linux 64-bit OS.

Depending on which flavor of Linux you’ve selected in the previous step, send the Console or Desktop ZIP to your board, run it and configure the settings.

Inside Xojo, go to Preferences and press on the Debugging tab.

That’s it. Now you will be able to remotely run and debug your applications. Add a few breakpoints and the execution will stop as soon as it reaches it, allowing you to explore the current state.

Deploying the final version

Once you’re ready to build the final version of your application, all the wires attached and components soldered, the last step is to “Deploy” your application.

There is a tutorial covering this step in detail: Deploying Web Apps on Linux.

If you create a Raspberry Pi project, please make sure you open a Forum thread. The Xojo community loves seeing this kind of projects!

What will you build?

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

Often when debugging an application, you’ll need to enter the same data in the same fields over and over. There is a temptation to set the value of the field to the test data. The downside of this is that you need to remove all those defaults before deploying your application.  What if some of those default values gives admin access to your database?

I add an Open event handler for those fields and use pragmas to keep the data secure. For example, in a text field open event handler I’ll put the code:

Sub Open() Handles Open
 #If DebugBuild
  me.Value = "wayneg@axisdirect.nz"
 #EndIf
End Sub

When building a deployable version of the application an empty event hander method will be included and my email address will be kept private. Now, I don’t need to remove private data from the project and it will still be there for the next release cycle.

Wayne Golding has been a Xojo developer since 2005 and is a Xojo MVP. He operates the IT Company Axis Direct Ltd which primarily develops applications using Xojo that integrate with Xero www.xero.com. Wayne’s hobby is robotics where he uses Xojo to build applications for his Raspberry Pi, often implementing IoT for remote control.

At that time, Xojo did not have this feature, but I did say that I thought it sounded pretty useful.

I’m happy to let you know that as of 2019r2, Xojo now has this feature. We call it Ignore All Breakpoints and you can turn it on or off from the Project -> Breakpoint -> Ignore All menu. A checkmark appears next to this menu when Ignore breakpoints is active. And when active, Xojo will not stop at any of your breakpoints. You can turn it on or off during the debug run as needed.

2019r2 also has a couple other improvements to the debugger as well:

• The debugger no longer stops at breakpoints within encrypted classes. This was not helpful and actually rather confusing since you couldn’t see the code.
• Breakpoints set within a Module Class Method during a debugging session now properly break in the debugger.

Xojo 2019 Release 2 has lots of new features and improvements, so be sure to download it today and review the full Release Notes.

if j >= 145 condition then dosomething()

or

if condition then return

might not have any downsides. I would argue that they do.

You can’t put a break point on the code that runs when the condition is true. And though sometimes this may not matter, when it does, like when you want to step into the method or code that is run, you have to turn the one-liner into a multi-line If…End If statement.^*

if j >= 145 condition then 
  dosomething()
end if

or

if condition then 
  return
end if

This allows you to put the break point on the code and not on the conditional. If it is code that gets run a lot, this can be a big deal.

This is why, as I go through the Xojo IDE code base, I usually remove one-liners and turn them into multi-line if … end if statements. This way I can break on the code and not the conditional, and in some cases this saves many hundreds of calls and having to step through the code.

As always, remember that what you do today can save your sanity or break it tomorrow!

^* Yes if you want to debug the called method every time you can put the break point in the called method. If you want to only break in this specific case, you have to rewrite the if statement so you can put a break on the method call line.

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. 

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.

The book includes 8 step-by-step projects for creating a variety of Xojo apps for the Raspberry Pi, including: a text adventure, a music player, a game, Internet access, a web app, plus hardware projects.

Raspberry Pi + Xojo is a great way for anyone to learn about computers and how to be a programmer. Check out the table of contents:

1. About Raspberry Pi
2. Setting Up Your Raspberry Pi
3. Xojo Overview
4. Remote Debugging
5. Xojo Programming
6. Program Structure
7. OOP with Classes
8. Project: Find Seltzer Text Adventure
9. Files
10. Graphical User Interfaces
11. Project: Music Player
12. Internet Access
13. Project: Cat Pictures
14. Project: Catch Xojo Game
15. Web Project: Family Notes
16. Interfacing Hardware with GPIO
17. GPIO Project: Blinking LED
18. GPIO Project: Digital Clock
19. What’s Next

Read the book online at the Xojo Dev Center or download a PDF.

• Programming the Raspberry Pi with Xojo (Dev Center)
• Programming the Raspberry Pi with Xojo (PDF)

Using the Remote Debugger means that you can now run Xojo apps on the Pi for testing and development without having to first purchase a Xojo license.

We’ve put together a short video to quickly walk you through how to set up and use the Remote Debugger:

For more information about using Raspberry Pi with the Remote Debugger, refer to this topic in the Dev Center:

• Raspberry Pi Remote Debugging

What was discovered was perhaps something obvious: that a legal filename on OS X may not work when you try to remote debug to Windows.

What occurs is:

• the application gets built as it should on OS X for Windows (a Windows exe + dll’s etc) into a tar file
• the copy files step executes and inserts the files into the tar file
• the tar file is transmitted to the Windows Remote Debugger Stub
• the tar file is then un-tarred

It is this last step is where things fail.

OS X has no trouble with a filenames that contain characters that are illegal on Windows. In particular, a “:” is allowed on OS X, but not on Windows. The reverse is also true if you work on Windows and remote debug to OS X, as there are characters that OS X won’t accept that are legal on Windows. Apple has a great guideline for cross-platform filename best practices and conventions.

So the copy file step can copy in a file that has an illegal name as far as Windows is concerned, but not OS X. When the un-tarring fails to create this file it also (currently) fails to let you know it failed. So the remote stub will still try and launch the application which fails because necessary items are now missing. Check for this situation if you’re having odd problems remote debugging. An update to the remote stub is in development that fixes this problem.

But for those times when you write some code and you just can’t figure out why its not behaving, there is always the Debugger!

The best part is the Debugger is very easy to use and it can help you sort out a lot of common issues. Its covered in the Xojo User’s Guide, specifically see the Using the Debugger section.

Let’s suppose you have an application and you have some code in the action event of a button that is giving you trouble. Open that event handler:

Now, set a breakpoint or a spot where your code will stop.

To do this, click in the left hand gutter on the dash or put the insertion point on the line you want a break point on and select Project > Breakpoint > Turn On.

The red dot indicates you have an active breakpoint on this line.

Now, when you run your application and press the button the code will execute and stop on the line marked. Note that it stops on this line BEFORE executing the line.

Now each time you press the Step button , the line of code will be executed and the program will stop BEFORE executing the next line.

And at each step you can see the values of the variables in the lower right hand variable viewer pane. If your calculation is having problems, you can step through it line by line and examine the values to see where things have gone awry.

Now you might think all this is well and good but there is no line after the one that sets returnpcnt.Text. What is the debugger going to do in that case? Well if you press step you’ll see that the debugger stops BEFORE exiting your code so you can indeed examine the values from the last line of code just as easily.

Learn to use the debugger. It will make life a whole lot easier for you. Of course in a short blog post I can only cover so much so visit the Xojo Dev Center to learn more.

Have fun.