With this feature you can provide custom drawing for a control at design time, making it easier to visualize your UI without running the project.

If this sounds familiar, it’s because it brings Desktop and iOS/Android projects closer to what’s already possible in Web projects with WebSDKUIControl, where custom layout rendering has been available for some time.

Why this matters

Previously your custom Canvas controls would appear as generic placeholders, making it difficult to understand how they would look at runtime. Now you can:

• Render a preview of your control directly in the layout editor
• Display dynamic or state-based visuals
• Make custom controls much easier to work with at design time

How it works

For Desktop projects, you can subclass DesktopUIControl and implement the DrawControlInLayoutEditor event. Your drawing code is executed by the IDE as it renders the control in the layout. For iOS and Android projects, this event is available on MobileUIControl.

You can also use this event directly with DesktopCanvas and MobileCanvas controls, so you can start drawing in DrawControlInLayoutEditor without needing to subclass anything.

This event gives you the flexibility to draw whatever you need—shapes, text, or even simplified representations of runtime content. For example, a custom media player control could display a play button and timeline, or a chart control could render a sample graph.

A note about XojoScript limitations

One important detail to keep in mind is that DrawControlInLayoutEditor runs using XojoScript. This allows the IDE to safely execute your drawing code at design time, but it also means not everything you’d typically expect to use in Xojo is available, especially when it comes to the graphics APIs.

In practice, most common drawing operations—such as shapes, lines, and text—work as expected. However, in some cases these graphics calls use a slightly different API, as is the case with LinearGradientBrush.

Also, because this runs as XojoScript, you cannot call other methods from within your DrawControlInLayoutEditorcode. To access your control’s properties, you’ll need to use the built-in  ColorProperty, BooleanProperty, IntegerProperty, DoubleProperty, and StringProperty methods.

Support for more Graphics

In 2026r1, we’ve expanded the graphics capabilities available to DrawControlInLayoutEditor, building on what was previously supported for WebSDKUIControl. New additions include support for:

• LinearGradientBrush, PictureBrush, and ShadowBrush
• LineDash, LineDashOffset, LineCap, LineJoin, and MiterLimit
• Outline
• Scale, Rotate, and Translate
• SaveState, RestoreState
• Color constants (Red, Green, Blue, Yellow etc.)

Since XojoScript does not support the Pair type, the LinearGradientBrush API was adapted slightly:

Class LinearGradientBrush

  Sub Constructor()

  Sub AddStop(stop As Double, c As Color)

  Property StartPoint As Point
  Property EndPoint As Point

End Class

The main difference is how the brush is constructed and how stops are added, without needing Pair. With this new API, you can turn a basic graph into something much more visually appealing.

Turning off this feature

While many may prefer custom rendering for custom controls, it can become a bottleneck when a large number of controls are rendering content. If you prefer a less resource-intensive experience, you can disable this behavior in Settings → Layout by enabling the Static Rendering option.

Finally

With DrawControlInLayoutEditor now available for Desktop and Mobile projects, you can take advantage of the same benefits Web projects have enjoyed for years. Be sure to check out the new DrawControlInLayoutEditor example project, adapted from the WebSDK → CustomButton example. We hope you enjoy designing and previewing your custom controls with this new event—and yes, it also works in Libraries!

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

These new options are available in the Inspector Panel when selecting the Sign step available under Build Settings > macOS.

Requirements

In order to apply Sandboxing, Hardened Runtime and go through the Notarization process for your macOS app, you will need to make sure that the following is installed on your Mac:

• macOS 11.3 or later.
• Xcode 13 or later – Run it at least one time and make sure that all its required components and SDKs are installed.
• Apple Developer ID – This needs to be a paid Apple Developer membership. Also, make sure you have your Developer certificates installed in the Mac.
• A working Internet connection.

Sandboxing

With the Sandboxing switch enabled, you can access the associated editor in order to enable the appropriate entitlements for the purposes of the app.

The Sandboxing settings will be applied even when the app is run from the IDE (debug mode). That means that Sandboxing can be applied both using an Ad-Hoc Certificate or the user Developer ID Application Certificate.

Hardened Runtime

When the Hardened Runtime switch is enabled, you will be able to access the associated editor in order to set the appropriate hardening entitlements for the purposes of the app.

Note: The Hardened Runtime will not be applied when the project is run from the IDE.

When building the app, if Hardened Runtime is enabled and no Developer ID Application value is entered in the Developer ID field (that is, signed as ad-hoc), then the following dialog will be shown and the build process will stop.

Notarization

When the Notarization switch is enabled, it will automatically enable the Hardened Runtime Switch if it is not already enabled (because the Notarization process requires Hardened Runtime!).

With the Notarization switch enabled, you will be able to access the Setup dialog in order to setup the app-specific password required by this process to properly work. Creating this password only needs to be done one time, because it will be saved to the computer keychain and even synced via iCloud to others Macs from the same user (that is, iCloud account).

Note: As with the Hardened Runtime feature, the Notarization process will not take place if the project is run from the IDE.

When building the app, if Notarization is enabled and no Apple Development value is entered in the Developer ID field, then the following dialog will be shown and the build process will stop.

The Notarization process does require an active network connection to the Internet because it needs to talk with the Apple Service responsible of checking the app bundle contents. This means that the required time to complete the process will vary depending of your Internet connection speed and the load or availability of the Apple Notarization service itself.

Custom User Entitlements

Besides the entitlements you may have selected in the Sandboxing and Hardened Runtime editors, you may need to add other ones not available in these editors. This is something you can do through the User Entitlements field (.Plist file format). Such custom entitlements will be merged with the ones selected in the editors. If the custom entitlements entries collide with the ones selected in the editors, then the ones from the editors will be applied, discarding the duplicated ones found in the provided file.

Building macOS apps… from Windows

When the macOS app is built from Windows, and Sandboxing, Hardened Runtime or Notarization is applied (and optionally custom entitlements), then the final compressed archive will include all the required supporting files including the shell script required to run from a macOS computer to complete the signing process using the provided Apple Developer certificate (except the option to create an App-specific password for the Notarization step, because that can’t be done from Windows).

Summary

As you can see, Xojo 2024r4 streamlines the ability to apply Sandboxing, Hardened Runtime and Notarization to your macOS apps, and even run them as sandboxed from the IDE, so you can get better feedback during the debugging process to everything related with the access to files, network user, camera access, etc. That is, the same behaviour your users will have once they run the app downloaded from the Mac App Store or from your website.

See detailed steps in the Xojo Documentation. If you need to know about what Sandboxing, Hardened Runtime or Notarization means, please take a look to the “macOS Apps: From Sandboxing to Notarization, The Basics” blog post.

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

More in this series on distributing Mac apps:

• Sandboxing, Hardened Runtime and Notarization arrives to the Xojo IDE
• macOS Apps: From Sandboxing to Notarization, The Basics
• Uploading macOS Builds to App Store Connect
• Provisioning Profiles for macOS Apps

In this article we will highlight several functions provided by the Xojo IDE that allow you to speed up and improve productivity in your large projects.

Filter the Navigator

The Navigator filter field allows you to limit the number of visible items in a section to those matching the typed text. This can filter a list to include only the objects used, such as controls, or even items that match the names of events, methods, properties, constants, etc. -practically any of the items added to the project except the code itself.

If you need to keep all elements of your project visible while browsing through matching results, it is preferable to use the standard search which you can access using Command + F (on macOS) or Control + F (Windows and Linux).

Going Directly to a Project Item

However, there are many times when you know the exact name of the item you want to select/display; whether it’s the name of a method, event, or even a control itself. In these cases, it is much quicker to use the Project > Go to Location option (Command + Shift + L on macOS; Control + Shift + L on Windows and Linux).

When you select this command, a dialog box will appear where you can type the path of the item you want to select. So, for example, if you want to go to the method “myMethod” found in the window “MyWindow” you would type: “MyWindow.myMethod”. The text field in that dialog offers auto-completion which means that, in most cases, you will only have to start typing the name of the main item and use the Tab key to access the menu displaying all the matches to select any sub-item you wish to select.

Additionally, and unlike the filter field, the hierarchy of the project elements will remain visible in the Navigator as they are.

Powerful Searches

This is undoubtedly the most powerful option that you can access using the keyboard shortcut Command + F (on macOS) or Ctrl + F (Windows, Linux), or by clicking on the magnifying glass icon in the bottom bar of the IDE.

Once you access the Find panel and start typing in the search field, the list below will start to populate with all the matches (by default); but you will probably find it more useful in larger projects to have the list refresh after you press the Return key. To do this, go to the Preferences window and, in the General section, change the “Find/Filter results appear” option to “After pressing Enter/Return”.

While by default the Find window displays matches found throughout the entire project, there are times when you may want to narrow it down to either the selected item, including any subclasses that may be based on that item, or simply the item in question; you can do this by using the following buttons:

Another added advantage of the search area is that it keeps a history of previously performed searches, thus speeding up the process when you need to revisit a new group of elements. In addition, you can change from simple (textual) searches to the more powerful use of regular expressions (RegEx) when looking for elements in your project.

Of course, this same panel also allows you to replace the searched text with other text on all the matches shown… but be careful before confirming. Make sure that they truly apply to the elements you want and not to others just because they start with the same word entered in the search field!

Bookmarks: Sitting There for You

In many cases, you will use the above systems to edit the code in a given method or event; especially if these are areas of code that you visit frequently. If that is the case, then you will find Bookmarks a really useful feature.

You can add or remove Bookmarks in the code editor by accessing the contextual menu from the currently selected line of code. You can also add as many Bookmarks as you need to a single code block, which is especially useful for large blocks of code on a given method, for example.

Once you have all your Bookmarks defined, you will simply need to select the menu option Bookmarks > Show All to have them displayed in the search area where you can select them.

Tip: Use the Preferences > General > Menu > Edit Menu Shortcuts option to assign a keyboard shortcut to the Bookmarks > Show All command. This will make it quicker to update the bookmarks listed in the Search area when they are not listed.

Tabs and Workspaces

Sometimes it is preferable to have several items in view when working on a large project, so that you can switch between them quickly; or to have the Layout Editor and the Code Editor for the same object. This is where Tabs and Workspaces are extremely useful.

By default, the Xojo IDE window has a single tab that displays all the elements added to the project, but you can open as many tabs as you need, and these tabs will be preserved when you close and reopen the same project, just as Workspaces will.

So, if you need to focus on a particular module or class, you can double-click on the item in the Navigator to open it in a new tab. Want more clarity, especially if your tabs bar is overcrowded? In that case, you can drag the tab in question outside the window boundaries to open it as a new IDE window (a new Workspace). Of course, you can also use keyboard shortcuts to move between open tabs in a single IDE window.

As you can see, Workspaces are new IDE windows for a single project. In fact, you can have as many as you need using the New > Workspace menu option. However, this option is only recommended if your setup has a high-resolution screen or multiple screens connected to your computer.

Conclusions

As we have seen, using filtering, searches, bookmarks, tabs and even the “Go To Location” command, among other options mentioned, will greatly speed up navigation when you are working on large projects.

What other IDE techniques do you use? Share them with us on the Xojo Forum or on social media.

Happy programming with Xojo!

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

To start, when an example is selected in the New Project window you’ll find a description of that example. Plus we’ve included what kind of project it is (Console, Desktop, Mobile, Web), what platform it is intended for (Android, iOS, Linux, macOS, Raspberry Pi, Windows) and the path (location) for the example in the Examples hierarchy.

When typing in the search field the list of examples will be filtered not only by those matching the example project name, but also the description. So, for example, when the word “Canvas” is typed in the search field, the list will display projects that have the word “Canvas” in the file names and also in the description.

But in order to narrow down the matching results even more, it is now possible to filter examples using different criteria like Kind (Console, Desktop, Mobile, Web) or Platform (Android, iOS, Linux, macOS, Raspberry Pi, Windows). If you are interested in all the example projects showing how to use the Canvas specifically for the Desktop platform, we only need to use that filter and… voilà!

We hope that our users will appreciate this minor but substantial improvement when it come time to dig into the increasing number of available example projects in Xojo. Visit the Xojo Documentation to learn more.

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

Optimizing the Navigator

In Xojo 2023r4 we tackled a performance issue impacting the navigator’s speed, particularly during scrolling. Upon closer examination, we identified that the substantial consumption of resources and time was attributed to the rendering of these basic and compact navigator icons.

What was initially intended as a straightforward drawing of an icon, ended up becoming a needlessly intricate element that significantly impeded overall speed.

The Before and After

In 2023r3, a noticeable lag occurs during scrolling, with the thumbtrack failing to keep pace with the mouse movement.

In 2023r4, scrolling has been significantly improved and the thumbtrack now maintains synchronization with the mouse movement, resulting in a smoother experience.

What other benefits does this change offer?

Having pinpointed the root cause of this issue, we proceeded to implement updates across various instances where the needless drawing persisted. We identified a similar occurrence when rendering command bar icons affecting every keystroke in the code editor and movement in the layout editor. Refactoring this aspect is expected to enhance performance in these specific areas of the IDE. We trust that you will find the IDE more enjoyable following these small and simple changes.

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Prior to Xojo 2022r4 the preview for WebListBox instances was a mere gray box with a small icon inside. This isn’t very helpful for visualizing how your design will look when the control is filled with data.

Now, you will get a preview that more closely resembles to the one provided by the ListBox in Desktop projects. That means the WebListBox preview will display the columns adjusted to the provided columns width and also the initial values (if any). Additionally, WebListBox will react to the change of width in the Layout Editor.

This improvement gives you a much better idea on how your WebListBox will look when the app is run in a browser.

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

macOS Minimum Version

This new build setting is available in the Build Settings panel for desktop projects when the macOS entry is selected in the Navigator panel. It defaults to macOS 10.14.0 if nothing is entered; that is the minimum macOS version supported by Xojo as stated in the Minimum Requirements section of the Xojo documentation for deployed apps.

But you can certainly set a lower value in that field. Though you do so at your own risk since it will be below the minimum macOS version supported by Xojo. We know that many solutions out there will run without problems if you set a lower macOS version, but in more complex projects, or depending on the controls or framework functionality your app may be using, it may not work as you hope! Thus, make sure to test your macOS apps thoroughly when setting the minimum macOS version lower than the current supported one.

What happens if you set the macOS minimum version to a value higher than the one used by the computer you are using for developing and debugging your solutions from the IDE? Let’s say you are running Xojo under macOS 12.6.2 but you intend to build the final app for macOS 13.x. In that case, you’re safe! When debugging the app from the IDE the value entered in the macOS Minimum version Build Setting will have no effect, so you will continue debugging your code without problems.

It is only when you build the final app, using for example macOS 13.0 as the macOS Minimum Version in the Build Settings, and try to run it from a lower macOS version when you (or your users) will see a dialog similar to this one:

Build Settings for Windows

This updated build setting is available in the Build Settings panel for desktop projects when the Windows entry is selected in the Navigator panel. Now, the ability to set the app’s compatibility with Windows 10 and Windows 11 is set out very clearly. Additionally, compatibility with Windows 7 and Windows 8 is still possible but clearly marked as not officially Xojo supported versions.

So, as you can see, now it is possible to set more clearly the minimum OS versions both for your macOS and Windows apps using Xojo!

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

In addition, we’ve added a new Binary option which allows you to automatically create sets that aren’t mutually exclusive. That is, the values of the elements are automatically powers of two and can have binary operations applied to them:

This new feature comes with the requirement that they be placed inside a Module because they’re rendered into your project as a Class. The reason for this is that these classes automatically have some helper methods on them to make working with the binary data easier.

• An Operator_Convert which takes an Integer:
  Var x as MyEnum = 3 // MyEnum.George, MyEnum.John
  
• …as well as one that returns an integer:
  Var y as Integer = MyEnum.George // y = 2
  
• Automatic conversion to and from Integer:
  Var x as Integer = MyEnum.Ringo // x = 4
  
• Binary operations And, Or and Xor:
  Var x as MyEnum = MyEnum.Paul Or MyEnum.Mary // x has a value of 40
  
• Equality operations so you can compare the internal value of one instance to another:
  Var x as MyEnum = MyEnum.Paul
Var y as MyEnum = MyEnum.Ringo
If x = y Then
  
• Contains helper method:
  If x.Contains(MyEnum.Peter) Then
  
• A Read-Only Value property so you can see the internal value in the debugger

Just like regular Enumerations, the editor also allows you to explicitly specify the value of an element:

This is so instead of having to write:
Var x as MyEnum = MyEnum.George Or MyEnum.John Or MyEnum.Ringo Or MyEnum.Paul

You can simply write:
Var x as MyEnum = MyEnum.TheBeatles

We hope that you’ll enjoy this feature as much as we do!

We did this by creating a sensible set of API naming guidelines and then applying them to our existing APIs. APIs that followed the guidelines were left alone. Those that did not, were changed to meet them. Hindsight, as they say, is 20/20. Looking back, it would have been great had we established these guidelines way back in 1998 before we shipped v1.0 but we didn’t and the fact that we didn’t is no reason to avoid it now. We always plan for a long future ahead of us and thus have to be willing to make changes to make that future possible. That we are still here 20+ years later suggests we are doing something right.

If you are one of those long time users who has grown accustomed to the inconstancies that API 2.0 addresses, you might be wondering if there’s any value for you in using it. The answer is absolutely yes! While it will take a little time for you to get used to the new APIs, what you will find is that you become increasingly more productive because they are so consistent. You will find (as I did) that you can guess at what the API is and likely be correct. I personally made 95% of the Language Reference updates for API 2.0. The documentation wiki does not auto-complete so I had to double-check all the code I was updating. In no time I found that I rarely made errors because API 2.0 is so consistent. You will absolutely see productivity gains once you have used it for a short time.

While API 2.0 is a major step forward for Xojo in terms of intuitiveness and consistency, for those of you with large projects you may feel like migrating is a daunting task. Depending on size, there can be anywhere from a handful to thousands of deprecation warnings to deal with, each being a particular change that could be made.

You might be assuming you absolutely must upgrade your projects but that’s not necessarily the case. How much of a project you update and when depends significantly on how important it is for you to update your existing projects to API 2.0.

First, it’s important to understand that most of the deprecated APIs are going be around for a very long time. It’s possible (perhaps even likely) that they could continue to exist for the entire life of your software project. You could decide not to upgrade any portion of your project or only upgrade portions that require it and then only when necessary.

Many deprecated APIs still share their implementation with the API they replace. A good example is RecordSet.MoveNext and RowSet.MoveToNextRow. If a bug is fixed in MoveToNextRow it will also likely be fixed automatically in RecordSet.MoveNext even though that method is deprecated.

Should you find a bug in a deprecated API you are still using, first try the new, replacement API and see if the bug is no longer reproducible. If that’s the case, you have an immediate solution: just upgrade that one usage of the deprecated class to the new one.

If the bug still exists in the new, replacement class, please report the bug using Feedback. Once fixed, there’s a chance that it will be fixed in the deprecated class as well, assuming it still shares its underlying implementation with the old deprecated class which, again, is true in many cases.

When deciding what to do regarding API 2.0 and any particular project, your options are:

1. Not Upgrading – You could choose not to upgrade an existing project to API 2.0. You could then only upgrade portions of it should that become necessary due to a bug fix or the introduction of new features.
2. Upgrade Incrementally – Another option is to upgrade your code incrementally as an extra step before refactoring or adding new code to a particular part of a project. This is the path we have chosen for the Xojo IDE as it’s a very large project that would take many months to upgrade if we did it all at once.
3. Upgrade All At Once – Finally, you may decide to go ahead and upgrade your entire project all at once. This has the advantage of allowing you to focus exclusively on the new APIs and no longer have to switch between the old and the new when going back and forth between older projects and newer ones.

If you’re choosing not to upgrade an older project or do so incrementally and you find seeing the deprecation warnings distracting when you use the Analyze Project feature, you can turn off these warnings by choosing Project > Analysis Warnings.

API 2.0 was introduced with desktop projects but it will be coming to web projects in Web Framework 2.0, for mobile in Android and eventually iOS as well. As a result it will be important to use the new APIs but for many of you, using them only with new projects and/or sporadically with older projects, may make sense.

API 2.0 is a huge change and change can often be difficult. There’s certainly a lot of comfort to be found in the familiar. Still change is sometimes necessary to keep things moving forward. Fortunately, in the case of API 2.0, we have designed it so that you have tremendous flexibility in terms of what options you choose for existing projects.

• Read more blog posts about this transition.
• UserGuide: Moving Forward with API 2.0
• UserGuide: API 2 Guidelines

Improved Overall Speed
One of the most obvious areas that hurt people with large projects is the speed of the IDE itself. We worked on a number of pain points to improve the overall IDE experience. Specifically, we were looking for things which by themselves were not too bad, but in a cumulative effect they could take large chunks out of your day.

One such area was in saving text projects. Now you wouldn’t think that there was much room for improvement here, since it’s just File I/O right? We found an optimization point in the way we save Bookmarks and Breakpoints, which in the IDE project represents a huge savings when making lots of changes. In our case, we went from 30 seconds down to 1, and for someone who insists on saving before every run, it makes a huge difference.

We also optimized drawing in the Navigator, and that change resulted in huge overall speed increases in many parts of the IDE, from selecting large number of items in the Navigator itself, making changes to multiple items, to even just typing code in the code editor.

Improved Tab Management
Tabs have been broken in one way or another for a long time. They finally got some TLC this cycle and we think you’re going to be much happier with the way they work now. We’ve rewritten the logic surrounding how tabs are chosen when you take an action which results in a new location request and made the behavior consistent, no matter where that request comes from. Whether that’s a Go To Location request or a search or clicking on an error result. The rules are applied in the following order:

1. If there is at least one locked tab which matches the Go To target, the first one will be used (left to right).
2. If there is at least one unlocked tab which matches the Go To target, the first one will be replaced.
3. If the current tab is unlocked, it will be replaced with the new location.
4. If there are any unlocked tabs, the first one will be replaced.
5. If none of the above conditions are met, a new tab will be created for the target location.

NOTE: Debugger Tabs are never eligible as a Go To target. This may seem obvious, but it wasn’t always true before. Now it is. Debugger tabs are also locked by default and cannot be unlocked.

The only exceptions to these rules are the Open In New Tab rules. That is, if you right-click on an item and select Open In New Tab or you double-click on an item with the “Double-click opens item in new tab” preference set, they will always open a new tab for you.

Once you start using the new logic, I think you’ll agree that it’s much more intuitive and you won’t feel like the IDE is constantly switching contexts on you. Personally I find that I’m using fewer tabs than in previous versions because I’m more confident that the objects I opened will still be there when I get back.

MacOS Dark Mode Layout Editor Toggling
On macOS 10.14 and above we’ve added a new toolbar button which allows you to quickly switch the Window you are editing between light and dark mode. No more switching your entire OS just to see how your app will look in the other mode.

Navigator Contextual Menu
We’ve done some cleanup work here to make it more obvious what you can and can’t do with objects in the Navigator. Gone are all of the disabled items that were not “in-context” for the currently selected item because, well duh, they’re not “in-context”. We’ve also enhanced the Edit Superclass and Edit Subclass menus. Edit Superclass now shows the entire superclass hierarchy, including things that you can’t edit (disabled of course) so you can track down common parentage. The Edit Subclass menu has been alphabetized so you don’t have to read the entire list just to find all of the items that begin with “c”.

Code Editor Contextual Menu
This menu has also gotten some love and attention. First of all, the menu has been reorganized so that the menu groups are based on the context of the thing that you’ve clicked on and the object where the code itself lives.

Group 1: Just like previous versions of the IDE, Cut, Copy, Paste, Delete and Select All are still at the top of the menu. They’re a common thing for mouse oriented users and we don’t want to hurt that functionality.

Group 2: The next group is for things that are for accessing or modifying the object that you’re currently editing. This is where you’ll find the Switch To menu for directly accessing the other code items within the current item.

We’ve also added two new submenus to this section that are specifically for copying the event and delegate signatures of the thing you’ve clicked on. For example if your code refers to a URLConnection object, you can now right-click on URLConnection and select Add Method > From Event > ContentReceived and the IDE will automatically add a method to the current object with the same signature including the object itself for use with AddHandler! In this case, you’d end up with a method that looks like this:

URLConnection_ContentReceived(obj As URLConnection, URL As String, HTTPStatus As Integer, content As String)

Then you could type something like:

AddHandler h.ContentReceived, AddressOf URLConnection_ContentReceived

Delegates work the same way, albeit without including the object reference in the method signature. No more flipping back and forth between your current code and the target object or Language Reference to copy the signatures!

Group 3: If it exists, this group is for things that are specific to the object or instance of the object that you clicked on in the code editor. This is where you’ll see the “Find” and “Go To” menu items for finding other uses of or going to the definition of an item, respectively.

Group 4: This group is for selection and code-specific tools including the Insert Color command, Standardize Format and the Wrap In menus for wrapping the current selection if an #If #EndIf or While/Wend block. This section also sports the menu for converting the current selection to a Constant or a Method.

Group 5: From here you can toggle Breakpoints and Bookmarks

Group 6: Help and Language Reference access.

For more information about the changes in 2019r2, read the full Release Notes.

There’s an advanced feature in Xojo called Compiler Directives which allows you to direct the compiler to conditionally compile a block of code based on a boolean comparison. For instance, if you wanted to temporarily disable a block of code (as opposed to commenting it out) you could wrap your code like this:

#If False
  // Code that you don't want to compile
#EndIf

You can also use constants with the #if directive, so if you created a module called “Switches” and it contained a Public or Protected constant named “EnableDeepLearning” with a value of True or False you could write code like this:

#If Switches.EnableDeepLearning
  // Code for your deep learning feature goes here
  // This code will only be included in your app if EnableNewFeature is set to True
#EndIf

There are also some built-in constants for you to use. For instance, there are two constants that tell you which version of the IDE is running, one is a Double, the other is a String. Here’s an example which allows you to use the new Dark Mode capability depending on whether you’re running 2018r3 or something earlier:

#If XojoVersion < 2018.03
  Var myTextColor As Color = &c000000
#Else
  Var myTextColor As Color = &c1C1C1C
  If IsDarkMode Then
    myTextColor = &cFEFEFE
  End If
#EndIf

There are also build-in constants per platform and processor type:

#If TargetMacOS
  // macOS Specific Code
#ElseIf TargetWindows
  // Windows Specific Code
#ElseIf TargetLinux
  // Linux Specific Code
#ElseIf TargetIOS
  // iOS Specific Code
#EndIf

#If Target32Bit
  // Code for 32-Bit Processors
#ElseIf Target64Bit
  // Code for 64-Bit Processors
#ElseIf TargetARM
  // Code for ARM Processors
#EndIf

For more information on Compiler Directives, see https://documentation.xojo.com/＃If…＃Endif

In addition to code for specific platforms, sometimes you need to know the specific version of the OS that the user is running. In 2019r3 we added the System.Version method specifically for this purpose:

#If TargetMacOS
  If System.Version = "10.15" Then
    // Code that works exclusively on 10.15
  ElseIf System.Version >= "10.15.1"
    // Code that only works on 10.15.1 and above
  End If
#EndIf

If you’re working with Windows, keep in mind that System.Version returns NT System Versions, so you’ll need to compare to these values instead:

• Windows 10 = NT 10
• Windows 8.1 = NT 6.3
• Windows 8 = NT 6.2
• Windows 7 = NT 6.1
• Windows Vista = NT 6.0

For more information about System.Version, See http://documentation.xojo.com/api/os/system.html#system-version.

To activate dark mode in Mojave, go to System Preferences, click General and select the “dark” appearance. The entire UI will switch to a darker, more muted color scheme which can be easier on the eyes, especially at night.

Here is what the Xojo IDE looks like in dark mode:

In order for your apps to support dark mode you’ll have to rebuild them with Xojo 2018r3 with its support for dark mode. Once you open your project in 2018r3 go to Shared Build Settings and turn on the Supports Dark Mode property:

Note: This property defaults to OFF for existing projects and ON for new projects.

This will automatically cause the Xojo built-in controls to switch to dark mode when you run your app in dark mode on Mojave. Here is Eddie’s Electronics running in dark mode:

For your own graphics and custom controls you may need to update your drawing code so that you use darker colors and icons when in dark mode. There is now a new IsDarkMode global method that you can check to see if your app is running in dark mode so that you can choose a different color or image.

The App.AppearanceChanged event is called when the user switches between light and dark modes or when the accent color changes. You can use this to tell your UI to update or redraw as necessary.

Read more about this change and others coming to Xojo graphics and the IDE in this post. To learn how you can update your apps to work in dark mode, refer to the Dark Mode topic in the documentation.

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. 

No matter the what type of project you are creating, learn these tips to make using the Library and finding controls fast and easy.

Keep Library and Inspector Visible All The Time

Normally the Library shares the right side of the Workspace area with the Inspector (which is used to change control properties). You can display the Library and Inspector as palettes so you can keep both displayed at once, even on their own separate display.

Change Library View

The default Library view is to show large icons. But you may prefer an alternate view. Use the gear button in the Library to choose a view that works best for you.

Find Controls

Just start typing to find a control by name or use the Filter field to show controls by name or description.

Download the latest version of Xojo today! You can learn more about the Library in the User Guide.

With the move to LLVM as the backend of our compiler, the format of our Windows executables changed somewhat. LLVM puts the executable code in a different location that doesn’t set off those same flags for anti-virus software. If you’re having problems with such false positives, recompiling your apps for 64-bit may solve the problem. Doing this is not a 100% guarantee but it can reduce the chances of a false-positive occurring.

This is even more true if you are using console-based helper apps especially if you’re launching multiple instances of them. Despite this being a known and often-used technique for taking advantage of multiple cores (and one we wrote about recently), it can make anti-virus software more suspicious. If your helper app has code that the anti-virus software thinks is in the wrong place, recompiling it for 64-bit may help.

Having said all of this, false is still false. If your apps (compiled for 32-bit or 64-bit) are falsely identified as having a virus, contact the anti-virus software company so they can update their software. Many have established protocols for reporting false positives.

• Growing? Read how one Xojo user took his app from in-house to commercial,
• Transitioning Windows Graphics: Direct2D/DirectWrite,
• Remote Debugger for Raspberry Pi and the Programming with Raspberry Pi Book,
• Check out our highly popular JSON Feed blog post series for iOS, web and Desktop,
• We updated Xojo’s Linux Desktop framework to GTK3 and HiDPI,
• Whatever happens, Xojo has your back if Mac goes ARM, and
• Jump into our ongoing Compiler blog post series: LLVM Everywhere, Compiler 101 – Overview and Lexer, and Compilers 102 – Parser.

A special mention on the topic of Net Neutrality in the US. Geoff has shared his point of view and we hope you make your voice heard to the FCC before December 14th. This is an issue that effects us all.

The Xojo community continues to grow with developers switching from VB, emerging citizen developers and small businesses all discovering what they can with Xojo. In the last 12 months the Xojo Forum has welcomed 1,688 new forum members and 60,772 forum posts.

Our blog post from back in June, Daring to Defy Software Extinction sums up Xojo and Dev Tool history with some perspective. We’re proud of what we, along with the Xojo Community, have built over the past 21 years and we look forward to 2018 – Android support, I’m looking at you!

From everyone at Xojo, thank you for your continued support. This community is truly one-of-a-kind and we look forward to all that 2018 has in store!

For users with large projects (and the Xojo IDE itself is a very large project as well), even 4GB of RAM isn’t enough. For these users, Xojo sometimes runs out of memory. That’s why I’m pleased to announce that today we are shipping a Beta of Xojo 2017 r3 as a 64-bit application. Xojo has provided the ability to build 64-bit applications since earlier this year but now the Xojo IDE itself is a 64-bit application which is a first after 19 years of being 32-bit.

Starting with 2017r3 the Xojo IDE will be able to use all the memory you could possibly have in your computer which means out of memory problems are now going to be a thing of the past. Modernizing Xojo, as we do year after year, keeps it in good shape so that you can depend on it for the foreseeable future.

For those of you have that been Xojo users for many, many years (and there are many of you that were here from the beginning), I thank you for your continued support.

Like PHP, Xojo is object-oriented. Unlike PHP, Xojo has a coherent framework design that is easy to work with; plus the Xojo language is simple and focused.

Work Faster with an IDE

Save yourself time and trouble by using an integrated development environment (IDE). Why juggle text editors, FTP software, web servers and everything else you need to develop using PHP? With Xojo, you just need the IDE itself. Plus Xojo has a visual layout designer. You can design your web pages by dragging and dropping controls and positioning things how you want.

Learn One Thing

Rather than having to master the details of PHP, HTML, JavaScript, AJAX, CSS and other somewhat related technologies, with Xojo you only have to know Xojo. You write your code in the Xojo language. Don’t worry about HTML or JavaScript -although you can if you want, Xojo is flexible. Xojo creates the HTML, CSS, JavaScript and AJAX code on the fly at runtime.

Expandable

Do you have existing JavaScript controls that you want to use? Take advantage of the Xojo Web SDK, which provides an API for you to integrate JavaScript (and HTML) controls and frameworks into Xojo.

This is Yahoo’s Rich Text Editor in a Xojo web app:

Easy Deployment

Of course you can deploy your web apps to your own properly configured servers. But if you don’t have web server configuration experience or you just want a simple and secure deployment option, you can use Xojo Cloud. Hosting with Xojo Cloud is as easy as clicking the “Deploy” button in Xojo; your app is built and uploaded to your Xojo Cloud server for immediate availability. You don’t have to worry about permissions, security or configuration.

See a Xojo web app hosted on Xojo Cloud here: http://demos.xojo.com

Free to Develop

Xojo is free to use for learning and development. Download and try it today and see why people are choosing the simplicity of Xojo.

Challenges

The foremost issue that we had to fix was that the original protocol was designed so that it required you to close the IPCSocket to get your command to run. That meant there was no longer a connection on which the IDE could send any kind of response. It also meant that dealing with issues required making multiple connections.

The second was that there were many things that raised dialogs when something went wrong, which meant that an unattended IDE could get “stuck” waiting for user input which would never come. We’d heard that developers would have their systems take a screenshot if an hour had passed with no activity so they could figure out what had gone wrong, but that can be a huge waste of time if you’re waiting on a build.

Solutions

The new protocol (which was beta in 2016r4 and officially released in 2017r1) addresses both of these problems. The new protocol uses JSON for the command format and the IDE can send back all kinds of information including (but not limited to):

* Script syntax errors
* Script runtime errors
* IDE version conflicts
* Missing assets
* Compile errors

All of these things are returned to your calling script so you can take appropriate action. Because this is truly a two-way protocol now, you can also send data back to your script, like if you wanted to return the path of the built app back to your build system.

We’ve also been working to make anything that would normally show a dialog to the user gets sent back to the app communicating with the Xojo IDE. As far was we know, all but one was caught, and a fix for it has been submitted for 2017r2.

If you’d like to see the new IDECommunicator protocol in action, look in the Examples folder next to the IDE: Examples > Advanced > IDE Scripting > IDECommunicator > v2 > IDECommunicator-Tester.xojo_binary_project

For documentation and more information refer to the doc page here: IDE Communicator

Just a note for those of you who have already been using the IDECommunicator project (or something similar) for controlling your builds, when updating to the new protocol make sure you don’t include a QuitIDE command in the script you initially send to the IDE. Doing so will cause the IDE to quit before you get a response which would present as a false positive. I suggest waiting until you do get a response and then issue a separate QuitIDE command at the end.

In the General Preferences there is an item for “Menu shortcuts”. You can click the Edit button to open the editor which opens a ListBox where you can view the entire menu structure and change or assign shortcuts to any item:

If you mess anything up, just click “Restore Defaults”. Enjoy!

You will have times when SVN will update the files on your drive, such as when you update from the server. Xojo does not automatically detect these changes, so most people resort to closing the project file and re-opening it in order to get the new changes displayed in Xojo. In fact, Xojo includes an IDE script to do just that: Examples/Advanced/IDE Scripting/ReloadProject.

There’s another solution. Here’s my tip for what I do to quickly have the IDE load those changes without having to close and re-open the project:

• Save my changes in Xojo
• Merge incoming changes from SVN to my local working copy
• Touch ONE item in the IDE. For example, change one letter in a property and then change it back.
• Select File->Revert to Saved

Voila! The newly merged code on the disk is loaded into the Xojo IDE. It’s a simple, quick way to work with your Xojo code and SVN.

Wouldn’t it be great to have that same access via the Inspector for your own classes? It would be simple to define the initial settings for your instances instead of putting the related code in the Open Event Handler. Well it is in fact, possible for you to decide what properties can be settable via the Inspector and even provide their default values and instruct an enumerator list for those properties of numerical type. It’s a nice touch if you are designing classes for your own use but also those you expect (and hope!) will be used by other Xojo developers!

In fact, through the Inspector Behavior feature you can further decide to disable those properties that are shown by default in the Xojo Frameworks. Why you would like to do that? Maybe to avoid problems or limit the things that others developers of the project can modify by default from the IDE (or consumers for your classes).

Accessing the Inspector Behavior

To do this, choose the class definition from the Navigator and then select Inspector Behavior from the contextual menu:

Using the Inspector Behaviour Features

This takes you to the window showing all the available properties for the selected class, including those inherited from their class hierarchy and those specifically defined by you. This is, in fact, the window where we can enable the checkbox for the properties we want to be shown in the Inspector and even create new headers in order to group these properties by category. Obviously, we can also disable the checkboxes associated to the Properties we don’t want to be available from the Inspector.

As you can see in the screenshot, the example shows a very basic class that has four defined properties whose types are Color, Text and Integer.

Once they are enabled in the Inspector Behavior window, these will be shown in the Inspector, so it is easier for the class consumers to define the used colors and other initial attributes from the IDE.

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

*Read this post in Spanish

You can watch the video (in Spanish, with English subtitles) as you read and work through this post.

It’s all about the content: Text

The main property of the control is the Text property. Accessing this property we can get the text typed by the user of the app…or set the text that we want the control to show (using Text or String data types). This property is available for all the supported platforms without variations.

Obviously, we can set the text shown by the control by default using the Initial State section of the Inspector Panel. Here is where we can find the CueText property for Web and Desktop apps, or the PlaceHolder property for iOS apps. Anyway, the text put here will be shown as ghost text by the control when there is not text entered from the user, giving a hint to the user about the kind of input data our app expect to be entered in the control instance.

Optionally, the Desktop and Web implementations of this control also offer the HelpTag property. Here is we can enter the text to be show to the user as a little help about the control purpose. This text will be automatically shown when the user puts the mouse pointer over the control during a second or so.

Give me the Password

Sometimes it’s very convenient to use the boolean property Password. Once enabled, the TextField will hide the control content from prying eyes, using a series of dots instead of every one of the typed characters. This is, in fact, the way to go when we need that the user of the app enters a Password or any kind of sensible data that shouldn’t be exposed otherwise.

As it happens with the Text property, the Password property is available for the creation and deployment of Desktop Apps (macOS, Windows, Linux, Raspberry Pi), web and native iOS apps. The only difference is that, for web apps, the TextField control will offer the option to save the password for later retrieval, something that only is available for that web browsers that support this feature (as it is with Safari under macOS). For iOS apps, the password behaviour will be the one we can expect from a native iOS app, showing in a fast succession the tapped key and hiding it in the blink of a eye.

TextField appearance

When it’s about the properties related mainly to the appearance of the text shown by this control, we can set several properties under the Attributes Inspector Panel for Desktop apps, as for example the Type, text Size and Style, as its the case when using this control in iOS apps. In addition, we can use the main area of the Properties Inspector to change the text alignment, text color and also the background color (only for Desktop apps, not in the case of iOS apps).

When it’s about web apps, all the issues related with the text style are related with the assignment of a Web Style that we have had defined previously, and whose creation and assignment is pointed in the video accompanying this blog entry.

When using this control on Desktop apps we can also set other appearance attributes, for example, the use of a border (it is not possible to assign the border color and/or border thickness), the use of the focus ring that points out the control active to receive the user keyboard input, and the feature already exposed that allows us to define the control background color; something that is also possible when using the control with Web apps, via the associated property during a Web Style definition.

How to limit the text length

There are several ways to limit the length of the text that the user can type on a TextField, mainly by kind of data or number of characters. The simpler is obviously the second option, available when using the TextField on Desktop apps and Web apps, via the LimitText property.

Applying format to the Text

There are countless the kind of apps where we would want to apply a specific format to the text typed by the user, and in fact we can turn again to the TextField properties to find the way to do it! However, we will have more or less flexibility if we are dealing with a Desktop app, a Web app or an iOS app.

Desktop

For example, when using a TextField with Desktop apps (macOS, Windows, Linux), we can use the Mask property to apply an specific format to the typed data. In these cases, the format will be applied once the control loses its focus. For example, the following format sequence applied in the Mask property:

###,###.00\ \€

will automatically format the number “123456” as:

123.456,00 €

Notice that even if we use the English notation (the comma as thousands separator and the dot as decimal separator), our app will apply the regional settings configured on the computer that runs the app. I mean, it will format correctly the string using the appropriate regional settings on every case.

Web

In this case we could talk about a combination between text format and text restriction. For that, we can choose any of the options available under the popup menu Type under the Appearance section of the Inspector Panel:

• Normal. The WebTextField will show any typed text.
• Password. It will behave as explained under the Password section, hiding the typed text.
• E-mail Address. The control will show an error ring if the typed text doesn’t seems to be a legal e-mail address. For that, it only seeks for the presence of the ‘at’ symbol (‘@’) and a dot character (‘.’) in the entered text.
• Number. The control will show an error ring if the typed content is not exclusively numeric. This is something similar to the example we have seen with the Mask in a Desktop app, except that in this case the control adds a couple of graphical widgets that allows us to increase or decrease the TextField value when clicking on them.
• Telephone Number. At first, this option should accept only the input of a legal phone number, but in practice it will admit any kind of data.
• URL. As it happens with the previous item, it should admit and show just the kind of data for a legal URL, but in practice it will admit any text composition.

iOS

In this case it is mainly about setting the kind of keyboard shown to the user once he taps on the TextField, where we can choose the most adequate for numeric values, URL, e-mail or general text, between some of all the available options.

So that’s the TextField control. You can watch the video (in Spanish, with English subtitles) that talks you though this example. And remember, when you have questions visit the Xojo Dev Center for documentation, examples, tutorials and more. Or ask the Xojo community on the Forums.

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

*Read this post in Spanish

If you missed it, the recording of the presentation is available in the Dev Center: What is Xojo?

Q: I would use Microsoft SQL Server Express with Xojo Lite. Is this possible?

A: You can certainly use Microsoft SQL Server with Xojo, but you will need to upgrade to a Desktop, Web or Xojo Pro license. Contact customer support to get a quote.

Q: Will Xojo be supporting build apps for Android?

A: Yes! We announced plans for Xojo to be able to create Android apps at the Xojo Developer Conference in October 2016. We will post milestones as we reach them on the Xojo blog.

Q: Is it possible to deploy an iOS app to my own iPad?

A: Yes, absolutely. If you don’t have an Apple Developer account, you can follow these steps to get your free Provisioning Profile from Apple. If you do have an Apple Developer account, the steps are much easier: Deploying to Device.

Q: Is there a way to show the Library and Inspector at same time?

A: Yes! Xojo has a preference to change the Library and Inspector to display as floating palettes. When you do this you can have both open at the same time and can even position them on a second display.

Q: Can iOS apps make use of low-level APIs?

A: You can use the Declare command to directly access iOS APIs. Some examples are also included with Xojo. The open-source iOSKit library provides access to many additional iOS features as well.

Q: How do you connect to database(s)?

A: Xojo has built-in support for SQLite, MySQL, PostgreSQL, Microsoft SQL Server and Oracle. In addition you can use ODBC to connect to any other database (as long as you have a driver).

Q: How easy is it to access the hardware features of apple devices, such as the GPS or its movements?

A: Xojo has a built-in class for accessing location/GPS information: iOSLocation. The iOSMotion class gives you access to information about device movement from the accelerometer and gyroscope.

Q: How do you create apps that work on both iPhone and iPad, switch screens as appropriate?

A: You can specify different views that are used for iPhone and iPads by setting the Screens. Also, the Split Screen topic in the User Guide shows how iPad apps can have two views displayed at once. There are a few example projects that show this as well:

• Examples/iOS/Apps/XojoNotes
• Examples/iOS/Navigation/SplitViewExample

Q: Where can I find Xojo training materials?

A: You can access our vast library of online learning materials at the Xojo Dev Center. There you will find Quick Starts, Tutorials, User Guide, Reference Guide, Videos and much more. From our Resources page you can access our free textbook, Introduction to Programming with Xojo, and our Teacher’s Guide. Join us for free webinars and virtual events, or watch on-demand webinars and video tutorials covering all kinds of topics. If you are interested in training, Xojo offers training and there are other options in our Add-On Store.

Q: How would I transition a desktop Xojo app to a web service + custom web UI?

A: You can move your desktop app’s business logic to a web app that functions as a web service. More information about that is in the Web Services topic, which has links to many videos on this topic. Another option to help with this is the Luna open-source framework. Once you have your web service set up, you can use the HTTPSocket in desktop, web or iOS apps to connect and use the web service.

Q: As a Filemaker developer, can Xojo display/play photos,video, mp3 files?

A: Yes, Xojo has built-in controls to display pictures, play video and mp3 files. Some of them include: ImageWell, WebImageView, iOSImageView, MoviePlayer, WebMoviePlayer. Also there is a web project that shows how to play audio using HTML5: Examples/Web/Controls/AudioPlayer.

Q: How do I convert my FileMaker Apps (desktop and mobile apps) to Xojo?

A: You’ll find some ideas at the Migrating from FileMaker topic at the Dev Center.

Q: Where can I find examples for developing Xojo plugins?

A: Included in your Xojo download (in the Extras folder) is the PluginsSDK, which has documentation and examples on how to create your own plugins.

Q: Can you say a bit about reports?

A: Xojo desktop projects can use the Report Layout Editor to design reports that can be printed or displayed on the screen. There are also several 3rd-party reporting products available.

Q: Info about Raspberry Pi and for Apple TV?

A: Xojo can create desktop, web and console apps that run on Raspberry Pi 2 and 3. You can find more information, with some example hardware projects here: Raspberry Pi. Xojo cannot directly create Apple TV apps, but you can use a Xojo web app as a web service to send content to Apple TV TVML apps using the open-source Viewpoint project shown by Tim Dietrich in the most recent Virtual Xojo User Group meeting.

Q: What happens with my Xojo Apps when the user updates their Operating System? Will I have to make an update for the Apps?

A: Your Xojo apps are generally not affected by OS updates. Of course, you’ll want to use the latest version of Xojo to ensure you have the most recent support for the latest operating systems.

Q: How active is the referral forum for the Pro users, specifically from the freelance developer perspective?

A: This varies greatly, but currently there are about 2 posts per week on average with about 28 items currently listed.

Thanks!

Thanks to all the attendees for the great questions! Be sure to give Xojo a try today. It’s free! You’ll soon be making apps faster than you ever thought possible. Additional “What is Xojo?” webinars are scheduled for February and March. Be sure to join so you can ask your own questions. For more casual conversations, join our Lunch with Xojo hangouts in February and March.

In 2016 we took many big steps forward with Xojo including HiDPI support for macOS (Retina), Windows and the web, hardware-acellerated graphics for Windows, tons of new iOS features, IDE improvements and compiler optimization for 64-bit builds. Check out the 2016 Release Highlights. The Xojo Forum has grown to over 16,000 members. We published our 100th video in the Xojo YouTube Channel and added new playlists for Raspberry Pi and Web Services and more new videos in our Spanish, Italian and German language playlists.

We hosted another highly successful Xojo Developer Conference in Houston, Texas and we’ll have an announcement soon about the next XDC. 2016 was another great year for Xojo and 2017 is looking even better! One of my favorite things is hearing about all the cool projects our users create and I have no doubt that there will be many more this year.

From everyone here at Xojo, Happy New Year!