Xojo 2014 Release 3.1

Xojo 2014 Release 3.1 hit the internet today. This release is a minor maintenance release and is recommended for everyone.

Web received a number of fixes. Checkboxes now work properly on touch devices. Label offsets are calculated correctly when the initial text is an empty string. Labels that had been on a container that had been set invisible in the IDE and visible via code now appear properly.

It’s a shame that these bugs made it into release.  Beta testers were so enamored with iOS that desktop and web didn’t get much attention.  But then again I was using the beta’s for production web apps and didn’t spot these bugs either so my bad too.  They’re kind of obscure in how to set them up and I generally don’t do either of those.  Hopefully with 2015 R1 we’ll get some better testing for targets other than iOS.

iOS received a few critical fixes. The first is that SQLSelect and SQLExecute now work properly (it was randomizing the data). The second fixed soft declares.

If you have not played around with the iOS SQLiteDatabase class the SQLExecute and SQLSelect methods now have built in prepared statements so there’s no need to through the steps of creating the prepared statement and then binding the values.

The IDE received a few minor bug fixes.  So did the compiler.

I reported a bug with the new Xojo.Core.Timer.CallLater in Windows yesterday. It generates an exception in a compiled application but in the debugger it generates an exception in the IDE! Too weird to be anything bug true. :)

I am looking forward to 2015 (seems weird to be typing that) Release 1. It looks like iOS builds will be 64 bit in that release. That means that Xojo is creating 64 bit builds for standard and debug builds in the iOS Simulator (Intel) and, at a minimum, standard builds for device deployments (ARM).

Presumably, this means that the IDE can already understand 64 bit debugger instructions, right? Is 64 bit for other targets far behind? Let’s hope not!

We already know the fiasco over the FromText methods in the new framework are being addressed in 2015 R1. In addition to FromText Xojo will offer a much less stringent Parse method that should satisfy most developers.

Any bugs that you’ve seen in Release 3? Anything you’re really looking forward to in the next release?

Xojo 2014 Release 2.1

Xojo 2014 Release 2.1 was released this week. This maintenance release is huge in several important ways.

This is the last version of Xojo that will build Mac Carbon apps. The upcoming changes to the framework for iOS and 64bit (and who knows what else) have made it impossible (or at least unfeasible) for the engineering team to keep supporting the Carbon framework. So long Carbon, we have to split up. It’s you, really, not me.

Since this will be the last version to support Carbon some nagging bugs were fixed in the Carbon framework. The hard crash that occurred when creating a new instance of the XMLDocument has been fixed. In addition a bunch of plugin issues for Carbon were fixed.

Cocoa apps that use RegEx will now pass submission to the Mac App Store.

For web app developers a big change was made to HandleSpecialURL that breaks everything that depended upon how the old, incorrect way, WebRequests were handled. I know this affects Web Custom Controls and it may also affect Studio Stable Web Essentials (unconfirmed). More info in a Xojo blog post at http://www.xojo.com/blog/en/2014/08/handlespecialurl-changes-in-2014r21.php

A few other web bugs were fixed. WebSession.Quit now properly clean and close the Session. A bug with WebContainer.EmbedWithin used in a open event (never a recommended way, if you ask me) that would cause WebLabels and WebLinks to offset was fixed.

There were several of database class changes too. SQLite now uses FTS4 with unicode61 tokenizer on Mac OS X. MySQLCommunityServer SQLExecute and Prepared statements no longer assume the statement is UTF8 encoded. The ODBCDatabase DatabaseRecord.Insert no longer inserts the wrong value.

As always, read the release notes for additional information and Feedback ID’s.

This dot release is critical for those developers still building for Carbon. iOS will (presumably) be out in Release 3 in at least beta form and the new framework is causing changes in a big way. I’m sure some of those changes will be subtle but some will be a smack to our collective faces.

To paraphrase Game of Thrones, “iOS is coming.” Sorry, couldn’t resist. :)

Xojo 2014 Release 2

Xojo 2014 Release 2 was released this week.  This release has around 200 bug fixes and enhancements, some new features, and some licensing changes.  A good portion of the changes and enhancements are in the Web framework which will make web developers very happy (I know I am!).

Licensing Changes

New Single Desktop licensing.  A new license is available for a single desktop platform (Mac OS X, Windows, Linux) at $99 each.  This is helpful if you are only dealing with a single platform and have no need for the other two.

Pro license is $100 cheaper.  A new Enterprise license is now available that gives you everything that the Pro license gives you plus 8 hours of custom video training.  The Enterprise license costs $1,999 for both new and renewal.


Users can now add plist items into the plist generated by the IDE at build time.  This takes the form of an XML file that is added to the project.  If this is something you’re interested in take a look at the Platform-Specific/OS X/PList/EnableRetina example.  If you were using an IDE script or PostBuild script on the Mac side to do this already I’m not sure that this is a better solution.  However, I think this will be hugely beneficial to Windows and Linux users that are building for Mac OS X.

The PostgreSQL database plugin now has an SSLAuthority FolderItem property that represents the root SSL certificate file.  This lets you connect to your database server using SSL.

Xojo Cloud users can now use the StageCode to create different builds for the server.  Final is the same as it was in the previous release but Beta, Alpha, and Development stages add a -Beta, -Alpha, and -Dev postfix, respectively, to the app name and upload them to the Xojo cloud server.  This should make it easier to test Xojo Cloud applications.  The only drawback I can think of is that smart users might figure out the URL postfix and use the newer version rather than the release.

Speaking of Xojo Cloud, release 2 seems to have finally fixed the hang on upload during large projects.  During the beta cycle I went from 1 out of 5 successfully uploading to a nearly 100% success rate.  Those that did fail didn’t require a restart of the IDE which was a royal pain in Release 1.

AddHandler and RemoveHandler now work with Web controls after they’ve been sent to the browser.  In previous editions you had to use AddHandler before it was sent.  For example, if you added a dynamic WebDialog you had to implement the AddHandler after it was created but before the Show method was called.  Now you can do that after the show.

The WebListBox received some love in this release.  A new SelectionStyle property now lets you set the WebStyle for row selections.  In addition to that, there is a new HeaderStyle and HeaderColumnStyle properties that let you select the header and column headers, respectively.

WebTextArea now has a ScrollPosition property that allows you to set the, wait for it, scroll position.

The WebToolbar has become more useful in that it allows you Append and Remove items.  This has been wanted for a while now.

In one of the bigger bugs that’s affect me for a while, they fixed the WebRequest.QueryString on cgi builds.  This now lets cgi builds to work the same as standalone builds.

WebContainers added via the EmbedWithin method now no longer have exponentially increasing delays.  This is very helpful to developers, like us, that use WebContainers a lot.  This change will let dynamic displays to be more responsive over time.

A bunch of Web framework items no longer leak memory.  Of note is the WebPage when closed and dynamic WebDialogs (i.e. created in code not placed on a page at design time).

A change was made to the Web framework to prevent ‘clickjacking’.  Clickjacking is an attack that tricks the web user into clicking something that is different from what they perceive.  This can potentially reveal malicious or confidential information or even allow taking control of the computer.  As far as I know, this attack has never occurred in a Xojo web app but it’s nice to see that they’re proactive on these things.

StyledText RTF parsing speed is improved.  This is a good thing since it was pretty much a dog before.

A number of console app memory leaks were fixed.

Some database changes:  SQLite is updated to use version 3.8.5.  The MSSQLServerPreparedStatemnt.SQLExecute no longer crashes.  MySQLCommunityServer no longer causes failed assertions when SQLSelect/Execute are invoked while other threads are running.  The Recordset.Update/Delete now works in SQLite databases when he primary key has special tokens (like single quotes) or BLOBS.  The error returned by SQLite databases using a bad encryption key is now the proper error.

Windows and Linux MsgBox and MessageDialog modality is now consistent.  This means that MsgBox is always app-modal but it depends with MessageDialog.  If called with ShowModal it is app-modal but if used with ShowModalWithin it is window-modal.

The IDE has a bunch of changes and improvements.  The long standing issue of changes in the Inspector not being retained unless you tab out of the TextField seem to be fixed.    Changes to non-text properties also commits the changes.  The Inspector has been compressed a bit to reduce scrolling.

In general, the IDE seems a bit snappier – at least on Mac OS X.  Sometimes it’s very hard to tell about fit and finish on the other platforms simply because I don’t develop on those platforms.


Xojo 2014 Release 2 is very much about the Web.  The memory leaks getting squashed, the WebListBox additions, and security improvements are all welcome.  Xojo Cloud is now functioning better and is now, in my opinion, worthy of being used on a day to day basis.  We’ve moved all of our training apps to Xojo Cloud during this beta cycle and are happy with the performance.

If you are not a Web developer than this release still has some changes and fixes that might be important to you. Unfortunately, in a review like this I can only comment on changes that seem important to me.  Check the release notes out!


What did I miss in the review that you thought was important?

Xojo 2014 Release 1

Xojo 2014 Release 1 hit the internet this week.  This substantial update fixes a number of issues, has some very nice enhancements, and has the long awaited release of Xojo Cloud.  So let’s dig in!

Xojo Cloud is, as the name implies, a hosting service for web applications written in Xojo.  It is a one-click deployment solution that greatly simplifies the process of deploying your Xojo web apps.  It really is pretty simple and there are really only a few caveats with using it.

Xojo Cloud is using RackSpace servers and there are three configurations that are currently available.  The small and cheapest server has 512 MB of RAM, 20GB of storage, and 1 Virtual CPU for $49/month.  The medium server has 1 GB of Ram, 40 GB of storage and 1 Virtual CPU for $99/month.  The biggest server has 2 GB of RAM, 80 GB of storage, and 2 Virtual CPU’s for $199/month.

This seems like a lot of money considering that a VPS offered by many hosting companies runs you about $400 a year (or less).  However, those VPS solutions are unmanaged and it’s up to you to keep them secure.  The Xojo Cloud solution has some pretty strict security that has intrusion detection and some other goodies that will make it difficult for an intruder to get to your application and data.  Add on that Xojo web apps are compiled and it makes for a pretty secure system.  Only time will tell how secure it is but unless you’re an expert on security it’s unlikely that your unmanaged VPS will be more secure.

Xojo web apps are guaranteed to work with Xojo Cloud (duh).  That’s not always the case with my experience with VPS solutions.  You have to worry about 32 bit compatibility libraries, permissions, and a whole host of other things that could go wrong.  Really, Xojo Cloud is a pretty decent value if you don’t like, or want, to manage your own server.

Xojo Cloud is a version 1 release.  There are a number of things that are not available yet.  For one, the server does not come with a database server though this is very high on their list.  During the alpha period I was able to, with the help of Xojo engineers, use a Rackspace Database Server (MySQL) working with a Xojo Web app.  Also, if you have a lot of storage needs (we have 40 GB of video for the Xojo Training Application) you probably will have to get a RackSpace Cloud Files account.  All-in-all it’s not very hard once you get it setup but RackSpace can be kind of daunting  as you wade through all of their options.

Xojo 2014 Release 1 comes with some Cloud specific framework additions.  The first is a TargetXojoCloud constant that lets you call code specific to Xojo Cloud.  One of those is the XojoCloud.FirewallPort method this allows you to open a port in the server firewall.  Once the reference goes out of scope the port is automatically closed.  If you do any communication with the outside world such as sending an email, you’ll need to open the port to the mail server.

There is currently no control panel to upload or view files.  Release 1 comes with an example on how to do this via a web app.  There are four areas that you can access on your server:  the application area, the Temporary directory, Shared Documents, and Documents.  The latter 3 can be access via the SpecialFolder object.  Accessing the Documents folder of your application creates a Documents directory next to the application and accessing the Shared Documents creates a Documents directory in the overall applications directory.

A few other miscellaneous things that are kind of a drag:  There’s no way to create testing builds without changing the name.  Ideally, I would want the Stage Code to let me make testing builds without affecting the production app.  My second issue is that as a consultant I will potentially have multiple clients with their own servers.  Currently there is no way to share servers. The good news is that both of these items are in development and could be added at almost any time.  I’ve been told that some Xojo Cloud enhancements don’t depend on the IDE release schedule.

The IDE has some Xojo Cloud specific additions as well.  In the Build Settings you’ll now find Xojo Cloud as one of the targets.  Once selected you’ll get Cloud Specific properties in the Inspector.  Currently there are only two:  The name of the application and a popupmenu listing your servers.

All-in-all, Xojo Cloud is a very good first release.  In the years that Web Edition has been around, deployment issues are the biggest headache for many.  It can be quite frustrating to deal with the various issues and while Xojo Cloud seems a bit pricey we plan on migrating our apps over to it (technically some already are but they’re not public yet).  File Storage and Database support is an extra addition, however, and some might find that unpalatable for now.

As if that wasn’t enough, there’s more!  Release 1 has a ton of fixes and enhancements.  The Layout Editors are MUCH speedier.  I have several layouts that in previous versions were almost unusable with web containers.  I had several web pages with fairly complex containers on them and when I selected one of them it would take a second for the Inspector to load and forget about doing a drag of the container as it would lag to the point of being worthless.  This enhancement alone is worth the upgrade, in my opinion.

The IDE received a bunch of love fixing some of the more painful bugs in the Navigator.  There are simply too many to list here but it’s a lot of changes in improving the user experience.  Some of the properties in the Inspector have now been migrated to the advanced tab of the Inspector.  The advanced tab used to contain only the Attributes panel but now some things like Font, Control Set, Focus and Database Bindings.  No great loss of those since they’re not changed very often (or even used).

The SQL Server database class was enhanced so that it works with SQL Server 2012.  This is good news for folks running Microsoft SQL Server.

Another big change in this release is the removal of QuickTime dependencies in the IDE and in Cocoa builds.  Apple has deprecated QuickTime and is rejecting apps from Mac App Store that use it.  In release 1 all framework references to QuickTime and QTKit are removed.  If you are using EditableMovie or any of the QuickTime decencies in the MoviePlayer you are out of luck.  There are currently no plans to replace EditableMovie.  Along with this, the MoviePlayer was rewritten to work without QuickTime.

A new language feature is the IF operator.  This is similar to the VB IIf or VB.Nets’s If operator.  An example is:  If(myInteger > 40, “Big number”, “Small number”).  My only beef with the IF operator is that the debugger can’t show you the results unless you have a local variable defined to show it.

I highly recommend that you peruse the release notes as there is a plethora of changes and enhancements listed.

What are your thoughts on Xojo Cloud and this release?

Edit: Fixed a few typo’s.

Xojo 2013 Release 4(.1)

Xojo 2013 Release 4 hit the internets this week.  And they promptly pulled it after they discovered a crashing issue when it tried to verify licensing on their servers.  Release 4.1 was released today which fixes the issue.  As far as I know, it’s the only fix in 4.1.

I would characterize Release 4 as a maintenance release as it has several hundred bug fixes and just a few new items. I’m okay with this and if I had any say in the matter I would alternate releases with new features and bug fixes. One thing this release does NOT include is the Xojo Cloud that has been in development for over a year.  I expect Xojo Cloud will be released for the 2014 Release 1 (so it will probably go into beta soon).

The big change in this release is that the IDE and applications built for Cocoa require Mac OS X 10.7 (Lion) or later.  I think this is a pretty good move though it will make life harder for some.  Apple updates their OS regularly and many update their OS when they can because the upgrades have been safe.  I can’t find the statistics but it appears that a vast majority (in the neighborhood of 80%) of Mac users are on 10.7 and above now.  Obviously, if you have clients and customers that require 10.6 (Snow Leopard) you’ll need to stick with Xojo 2013 Release 3 (or continue building in Carbon).

New in Release 4 is new cryptography functions using the Crypto class.  The new class adds RSA encryption to the Xojo framework.  It has functions that allow you to generate public and private keys, verify the keys, encrypt and decrypt data, sign data blocks, verify signatures, and generate a random block of data.

For desktop users, the Canvas and ContainerControls now have a transparent property.  The default is true to maintain current functionality.  This change is particularly important in Linux as child controls on an opaque (not transparent) canvas or container control can be clipped.

The IDE can now use constants for the application identifier which can be useful if your application has multiple names or versions.

Release 4 has a ton of bug fixes and tweaks to the IDE.  This includes many fixes and changes to the Navigator and some of the copy and paste bugs that have afflicted the IDE since its first release.  It’s still not perfect, but it’s getting better.

Better is subjective, of course, but one of the bigger annoyances to many users (including me) is that changing text values in the Inspector (such as a control name) didn’t actually stick unless you tabbed out of the field.  This has been fixed and just this one change alone is worth getting and using Release 4.

There are a few debugger changes that are worth mentioning.  First, the debugger now catches exceptions raised in computed properties.  Before it wouldn’t, which could cause navigating in the debugger to actually change the control flow of the program.  Second there are some specific fixes to the debugger for Windows and Linux users, and finally a new DebugIdentifier property was added to the Thread class to make it easier to debug code that’s running in a thread.

One item of note that came through late in the beta cycle.  Several developers had issues with rejections from the Mac App Store (MAS) due to using QuickTime API calls (or the framework linking to them).  It appears that Apple, while only deprecating QuickTime in Mavericks, is actively rejecting apps that use it.  Release 4 no longer links to QuickTime but according to the Beta list testers this is still an issue.  In my opinion, this is more an issue with Apple, suddenly and with little warning, rejecting MAS submissions than it is Xojo doing anything wrong.

While I like Apple, sometimes getting apps into their store is like hitting a moving target.  Apple giveth and Apple taketh away.  <insert favorite negative Apple cliche here>  If you know more on this, please add comments below.

What are your thoughts about Release 4?  Are you happier with the IDE after 4 releases than you were initially?  Are you looking forward to Xojo Cloud?  What about the eventual iOS support?

[Edit:  Changed wording on the debugger changes for computed properties so it was more accurate.]

Xojo Release 3

The third release of Xojo hit the internet this morning.  This release continues the incremental improvement and bug squashing that Release 2 did.  In addition, some nice new features were added that should make everyone happy although there is one major item that’s bound to give many users (or at least those not building for Cocoa) some heartburn.

The big change is that Windows and Linux desktop app developers can no longer access user interface elements from within a thread.  The behavior was always discouraged but not outright banned.  Now it is.  Just as it does in Cocoa, accessing any UI element from within a thread will cause a Thread Accessing UI exception to be thrown.  To workaround, you will have to have your thread fire a timer on your window or class which then updates the UI.  To see an example, look the Examples/Desktop/Threading/Threaded UI Update project.

Some good news for Web Edition users.  WebFiles can now point directly at FolderItems and can download incrementally in 64k chunks rather than having to load everything in RAM first before downloading.  The WebFileUploader can also take advantage of this new functionality as long as it has permissions to write to the temporary folder.

Another change that might affect a lot of developers was to the database server plugins.  Large queries could sometimes hang your application (because it was blocking the main thread).  I’m not sure when the Multi-threaded flag was added (Real Studio 2011-ish?) but it proved to be unsafe and caused occasional hard crashes.  In Release 3, if you call a large query on the main thread it will block (i.e. freeze) your application.  If you call it from a thread it will ‘just work’ but in a safe way so crashes don’t occur.

The number of IDE bugs squashed in this release is huge.  There are dozens of changes that fix some of the more annoying habits of the Navigator.  The entire IDE feels more solid and the Navigator much less twitchy.  Deleting children items in the Navigator no longer moves the focus back to the top of the Project tree.  Instead, it will try to select the next level up.  Converting methods to and from shared updates the Navigator properly now too.

Due to bugs caused by Navigator animation, it’s now been turned off until those bugs can be squashed.  The animations seemed useless to me by wasting cpu cycles.  Sure, it looked pretty but it didn’t DO anything for me as a developer.  Good riddance, in my opinion, and I hope they don’t come back.

The main IDE toolbar can be hidden and shown.  We still don’t have the ability to change the icon sizes, but it’s a start.    For Mac OS X users that like to run in fullscreen mode, hiding the toolbar seems to be impossible.  I’m not sure if this is an OS X issue or a bug but it seems pretty minor to me.

The Library filter has now been moved to the top to match the location of the Navigator filter.  I always thought it was silly to be on the bottom and I’m glad they’ve moved it.  In addition to that, both the Library/Inspector and Navigators can be made much smaller now.  The labels in the Inspector aren’t perfect but this a much needed improvement, in my opinion.

Also new is a new Run tab is opened when debugging an application.  When in the debugger and you select Edit Code it will take you to another tab so you don’t lose the Run tab.

A long term debugger issue was solved in this release.  If you stepped through code quickly (I call it spaz clicking) the debug app would usually crash.  This is no longer the case.

Windows users received some love in this release.  Windows flicker appears to have been reduced by being smarter on when to refresh the window.  Typing in the Code Editor seems to be much improved.  Memory leaks in graphics that use transparency are also fixed.

All in all, this release gives us some nice improvements for Desktop and Web Apps.  The IDE, Navigator and all, are shaping up (it still needs improvement but that’s a different post).  This is a recommend update to Release 2.

The full revision list is at  http://docs.xojo.com/index.php/Changes_2013r3

What’s your favorite addition/fix for Release 3?  Do you know of any bugs that made it through beta?

[Updated:  The IDE didn’t crash when spaz clicking in the debugger it was the debug app that crashed.]

An Apology

I need to apologize. My blog post from yesterday was disingenuous when I said:

Bugs that I know of that were reported during the beta cycle that weren’t fixed

It implies, incorrectly, that I felt Xojo wasn’t fixing bugs. These Feedback Reports (some of them by me) were submitted relatively late in the cycle. Sometimes there just isn’t time to fix everything that’s discovered.

Feedback 28167 (can’t change subclass supers) was reported the day before the release (July 15).

Feedback 28098 (deleting a control event) was reported July 11.

Feedback 28068 (weblistbox inline editor) was reported July 10.

Feedback 27742 (can’t copy/paste objects in different folders) was reported June 26. You could argue that this was early enough in the beta cycle but add in the 4th of July holiday in the US and it’s not quite so early as it seems.

We, as beta testers, feel that the beta cycle should be inclusive and bugs found in that cycle should be fixed IN THAT CYCLE. The reality is that the Xojo engineers are already working on the NEXT release (R3) and what we’re seeing is the work already done.

We can argue all day on whether or not Release 2 could have been held back another week to fix some of these more serious bugs but the reality is that sometimes a release happens for a variety of factors. Schedule, marketing, sales, the phases of the moon, etc.

Do these bugs affect everyone? I would argue that some of them do but hey, it took me weeks of using the R2 beta to discover some of them, so who am I to say? If they don’t affect you then they are of little importance. Heck, it’s entirely possible that these bugs were in Release 1 and I didn’t notice them in over 4 months worth of use.

My point is that instead of making it sound like I was accusing Xojo of issuing a crap release because they weren’t fixing bugs, I should have said that these bugs were discovered in the beta cycle and they hadn’t been fixed yet. I have done this in previous reviews and I should have stuck to that script rather than giving into sensationalism.

With all that said, Release 2 fixes a LOT of bugs. The release is more solid than Release 1. It does break a few things (the cookie expiration date being one of them) but Brad Hutchings has released a workaround in the Xojo forums https://forum.xojo.com/2753-cookies-expiration-don-t-work-in-r2-fc2.

My advice to all Xojo developers is to be paranoid about new releases. Keep good backups and I highly encourage everyone to use a version control system (subversion, git, cvs, etc) so something else is helping manage your source code. Your code is your most valuable asset so why not treat it like gold? Binary format is convenient but not very safe from corruption in my opinion.  At least with a version control system you only lose an object if it’s corrupted rather than the entire project.

Anyway, this post is almost as long as the review. People do read my stuff and I try to be truthful and helpful. I am a supporter of Xojo and when I’m critical of the product I’m just trying in my own way to make it better. Resorting to hype doesn’t help.

Xojo Release 2: Better but not Great

Xojo Inc released Xojo 2013 Release 2 this week. Release 2 has around 150 bug fixes and enhancements. Unfortunately, for Release 2, the IDE still has glaring holes and still isn’t good enough for every day use, in my opinion. Let’s talk about the major changes:

First, one of my chief complaints about Xojo, the vertical space taken up by the Inspector, has been taken care of. It’s vertical spacing is much improved and that’s very welcome. At lease when you look at a Listbox in the Inspector you don’t have to scroll three vertical lengths of the screen to see all the properties.

Unfortunately, the minimum width of the Inspector, Library and the Navigator have not been trimmed so your horizontal spacing is still compromised. I understand the value of incremental changes but this one seems like a half baked solution to the overall problem of fixing valuable screen real-estate issues.

There were a number of Cocoa issues fixed including Canvas Focus Rect, Window Live Resize, Applescripts, Metal Windows, Round Rectangles, Checkboxes in Listboxes, and Masks with pictures without alpha channels to name a few. I didn’t find any of these bugs so I can’t really talk about them very much.

The release notes claim that the Inspector flickers less in Windows. I have not checked so if you have any comments on them please leave them below.

For Web Edition, the WebSessionContext was fixed when server-side code tried to access the Session object. This affects a bunch of web developers so this is a welcome fix.

Overall, R2 feels more ‘solid’. I don’t know how to quantify that other than the impression that R2 is less twitchy and prone to doing extremely odd things like in R1. It’s still less than perfect as there are many things that still don’t work like I expect them to (such as locked tabs).

Bugs that I know of that were reported during the beta cycle that weren’t fixed (feel free to add more in the comments section):

• Changing the Super of Subclassed control back to its original subclass is impossible. <feedback://showreport?report_id=28167> Workaround is to rename the super manually via text editor and reopen the project.

• Deleting a control event is impossible. <feedback://showreport?report_id=28098> Workaround is to remove the offending event code manually via text editor. Marked as fixed but not for R2.

• Duplicating a Window/Page with containers results in a Window/Page with a blank object. (Can’t find the original report)

• The WebListbox Inline Editor is not invoked right away when the pencil icon is clicked and once open it doesn’t like to go away without clicking elsewhere in the layout editor. <feedback://showreport?report_id=28068>

• Copying/Pasting an object into a different folder doesn’t change their names properly. And once you’ve done that changes to the what appear to be the copy will sometimes change the original. The work around is to copy and paste them into the *same* folder and then move them to the new folder and rename as necessary. <feedback://showreport?report_id=27742>

• If you’re using WebSession.Cookies.Set with an expiration date it creates the cookie just without the expiration data. This appears to be a regression from R1. <feedback://showreport?report_id=28028>

• Constant issues with the focus being put somewhere I don’t want it. I’ll have a control highlighted in the Layout Editor, select Duplicate (from the contextual menu because the keyboard shortcuts usually don’t work) and instead of duplicating the control it will duplicate something in the Navigator. For instance I had several instances where an event was duplicated 3 times (because I hit duplicate 3 times) and I accidentally create 3 methods with the event name. (No report because I’ve not been able to duplicate said focus issues reliably.)

If I sound like I’m annoyed, I am. Xojo got incrementally better in some respects and worse in others. Some of those issues make it hard to use Xojo all day, every day.  Xojo *is* usable but not without being hyper vigilant. The fact that I’ve had to resort to the text editor to fix certain things is very troubling. This is not something I’d recommend for everyone and is impossible for those of us using the Binary format (i.e. those without a license).

During the beta cycle there was a fair amount of grumbling of bugs that hadn’t even been reviewed yet by the time Final Candidate was announced. Part of this might be because there is one less developer on the team (Thom McGrath is no longer with the company according to his LinkedIn profile) so they are trying to do the same amount of work with fewer people.  I don’t envy the developers their job.

I understand the need to get an update out the door but the cost of releasing new bugs discovered during the beta is very high. While R2 is usable I recommend vigilance and lots of backups if you are going to use it. Let us hope that R3 is released ‘quickly’ as well.

What is your opinion of R2?

How’s Your Xojo Mojo?

Xojo was released a week ago.  For those of us that were in the beta program (and even earlier with the alpha program) it seems like we’ve been using Xojo forever.  I have plenty of my own opinions and I can take some small satisfaction for saying, “I told you so” in some areas in regards to the new UI.

There are plenty of things in Xojo that I dislike.  The use of vertical space in the Inspector is atrocious.  The lack of keyboard shortcuts is annoying.  Getting lost in the Navigator makes me less efficient.  The inconsistent use of checkboxes vs sliders is disappointing considering this release was put on hold for a year.  Note that I didn’t say that any of these issues were show stoppers.

For me, the IDE has crashed some but not to the point where I want to put my fist through the screen.  I’ve gotten the Navigator so lost that it doesn’t redraw properly but a simple Xojo restart seems to fix that.  There have been times when the focus is somewhere other than where I want it and a Duplicate command creates a duplicate of something else entirely and sometimes it takes me a day to find the duplicates because they’re hidden in the Navigator.  Again, these are annoyances and not show stoppers.

I know that some Windows users are very unhappy with the new user interface and that for some Windows users the IDE is horribly slow and the flicker is bad.  I’ve not investigated this in any great detail but it seems to be related to GPU power and OS on the end users computer.

While there are plenty of things to dislike there are also things that I just use.  Xojo is usable for me and my team and I’ve spent a considerable amount of time using it (roughly 80% of my time) the past couple of weeks.  For me, the Cocoa framework seems to be solid and while some things are different I expected a certainly level of incompatibility.  It is after all a new framework that, while close to Carbon, is still different enough to cause some heartburn.  Really, the only major difference that I’ve seen is that using Threads is a pain now.  Software development isn’t always pretty or easy but Xojo has done a good job of making it easier.

I am looking forward to the future releases to see how they combat some of our biggest gripes.  A few changes can’t come soon enough but bottom line, for me anyway, is that I can use Xojo for consulting projects.  My fallback is always to go back to Real Studio but I don’t think I will need to.  The few times I’ve gone back into Real Studio I have discovered that it looks ‘strange’ now.  So give Xojo a chance.  It tends to grown you.

So what are your thoughts?  Do you like it, love it, hate it?  And why?

PS.  Let’s keep the remarks civil.  I don’t like it when users make personal attacks on me and my team in tech support.  I’d like to keep the comments respectful.  I’m friends with much of the Xojo team and I know they put in a ton of work for this release.  I for one will cut them some slack and I hope you will too.

Xojo 2013 Release 1

XojoXojo 2013 Release 1 is the biggest change to the Real Studio IDE since 2005 when the modern REALbasic/Real Studio IDE was introduced.  The User Interface, while still relatively familiar, has been changed throughout the IDE.  Some changes are blatantly evident and some look almost exactly as their Real Studio counterparts but regardless of looks almost everything was rewritten.

In addition to the major UI changes the Cocoa framework has been worked on extensively.  The Xojo IDE is compiled for Cocoa (on Mac OS X) and the beta tag has been lifted from Cocoa (yay!).  For many applications you will have to make few if any changes but if you’re a heavy user of threads it’s likely you’ll have your work cut out for you with the new ThreadAccessingUIException.

Without further ado, here is my review of Xojo 2013 Release 1.  I have some opinions and some pretty strong ones.  Expect a few in this review.  :)

Project Chooser ProjectChooser

Starting up Xojo is a bit faster than Real Studio.  Optimizations were made with the documentation and a new plugin format makes this a less onerous task.  When you start Xojo you’re presented with a new Project Chooser that lets you select the type of build (Desktop/Web/Console) you want.  You have the ability to input some data up front but it’s not mandatory.  The project chooser also has a way to quickly get to the example projects.



Gone from the IDE is the Project Tab.  In its place is a new Navigator that contains every item in the project as well a Build Settings.  These two groups can be collapsed and expanded independently.  When run your app in the IDE an additional section called Run is added that contains the debugger interface.  Once you stop this section disappears.

Content Section

The Content Section contains all of your project items.  This hierarchal list shows everything.  Every window, class, control, subclass, module, method, event, property, constant, structure, menubar, menu item (and more!) can be found in this list.  Open a Window to see the sections it contains whether that be constants, controls, methods, properties and events (more on events later).  Expand the individual sections to drill down into their contents.

As you select the various objects the appropriate editor is loaded into the center pane.  Click on a window and the layout editor appears.  Click on a menubar the menu editor appears.  Click on a constant the constants editor appears.  Click on a Method and the code editor appear.  You quickly get used to the right editor showing up at any given time.  As with Real Studio there are some funny things happening with the focus so to select an item in the Navigator it sometimes takes two clicks.

At the top of the Navigator are several controls to aid you in the search of your project items.  In the Filter field you can start typing the name of the item you’re looking for.    This is convenient if you already know the name of the item, but not so good if you don’t.

Double clicking on an item will drill down into that item and only that item is shown in the list.  Just below the Filter field is a Jump Bar that allows you to do a couple of things.  On the far right is a set of left and right arrays that let you navigate the hierarchy of the object you’re in.  On the left the current item is named and has a disclosure triangle next to it that displays a popup menu of the hierarchy allowing you to quickly navigate back to the top level or any level in between.

One of the goals in Xojo was to eliminate tab management.  If you really want a tab you can easily open the entire Navigator/editor structure into a new tab.  Simply right click on any item in the Navigator and select the Open in New Tab command.  There is also a Preference setting to allow a double click of any object to open in a new tab.  Some users may find this a more comfortable transition (I know I did).

The Navigator has some very handy features that the old Real Studio IDE didn’t do.  For one, you can select multiple items at the same time.  Have ten methods you want to copy and paste into another object?  Simply select the items you want, copy them, and paste in the new location.

One item of note here.  Keyboard handling can be tricky with copying of objects so I’ve gotten into the habit during the beta period to use right-click to copy items.  It is my belief that as this UI matures most of these inconsistencies will disappear.

Drag and drop from the Navigator is also possible in some editors.  For example, if you had a subclassed control (say a listbox) and found it in the Navigator you can drag and drop the subclass into your layout editor.  Since the Library doesn’t contain your project items this is the best way of adding subclassed controls to our layout (though you can always drag the original and then change the super).

One of the more annoying things the Navigator left out from Real Studio is that it doesn’t display super or data type information or interfaces.  You can get that information by selecting the item and looking at it in the Inspector (assuming the Inspector is open).  You can also see this by hovering your mouse over the item until the tooltip appears which gives you the missing information.  Regardless, both methods require additional work and are less than ideal.

Build Settings Section

Gone in Xojo is the Build Settings dialog.  The replacement is access through the Build Settings section of the Navigator.  In its place there are now 4 new sections allow you to access various settings.  The Shared settings replace much of what was in the Application object in Real Studio.  The Mac OS X, Windows, Linux, and This Computer sections let you change the settings for their respective platforms.  The platform options look like CheckBoxes in the list and, indeed, are checkboxes that tell Xojo which platforms to build for.

Run Section

If you decide to run the project from the IDE a new section appears on the Navigator called Run that contains one entry and that’s the debug instance of the application.  This is where you’ll see the slightly redefined runtime debugger.  The debugger is really just another editor and to start, stop, step into and out of code you have to go find the Run section and select the running application.

If you have multiple tabs open the debugger will always run in the first tab.  If you happen to close that tab the debug application is killed.  If you profile your application, the profiler instance will reside in the Run section.  More on Profiling later.


The main Xojo toolbar contains commonly used commands.  The toolbar is not customizable yet so you’re stuck with the big icons with text.


The Insert toolbar button is a menu button that mirrors the menu items in the Insert menu that’s located in the MenuBar.  This is the primary way to add things into your project.  You’ll use this button (and menu) quite a lot as you’re developing your applications.  In addition to adding objects, it’s also another way of adding events to objects (more on this later).

Another place the insert menu is available is in the right-click (Contextual Menu) of the Navigator.  Right click and along with numerous other options the Insert menu is available.  If you don’t want to move the mouse to the toolbar or menubar this is a good option.

Back/Forward Buttons

The back and forward buttons let you quickly navigate the history of each tab.  So if you look at the application object, then drill down to the App.Open event, and then go view a window the back button will take you to each of those.  This was a rather late addition to Xojo since so many people had complaints of ‘getting lost’ in the Navigator.  The history buttons definitely help out in this regard.


As with the Real Studio IDE, the Run button starts a debug session.  The compiler will start up and if no errors the Debug panel is loaded waiting for an exception or breakpoint.  At this point this is also when the Run Section is added to the Navigation list.


The Build button creates non-debug builds based on settings.  It will invoke the compiler as well.  Errors will be shown in the Errors pane (if there are any).  The Errors pane appears at the bottom of the screen.


The Help button invokes the Xojo online documentation that lets you access the Language Reference and all other documentation.  A preferences setting lets you choose On-Line or Local documentation.


The Feedback button opens the Feedback application.  Feedback is THE way to report bugs to Xojo Inc (after searching for existing reports) and to put votes toward those reports you want Xojo Inc to implement faster than others.


The Library button shows/hides the Library pane.  If the Inspector is visible it will replace it.


The Inspector button shows/hides the Inspector Pane.  If the Library is visible it will replace it.


In the Real Studio IDE the control palette was available for Layout Editor.  In Xojo it has been replaced with the Library panel and you get to choose when this is visible.  In the Xojo toolbar is a Library button that shows and hides the Library.  As with many things in Xojo this area has been completely redesigned with a number of options.

The first option is that you can view all controls or a subset at any given time.  Subsets are things like buttons, controllers, decor, indicators, etc.  Moving the mouse over any of the items in the list loads a brief description of that control into an information pane located at the bottom of the Library pane.

This Library list itself has a number of options that allow you change the view.  You can see the list as large or small icons with or without labels.  You also have the option of grouping them by category and sorting them alphabetically or not.  In addition to all that there is also a search field at the bottom of the Library that filters out controls based on name.

After playing around with settings for a while I settled on Small Icons with Labels, No grouping, but sorting alphabetically.  This as close as I come to the Real Studio control palettes.  I’ve also been finding myself using the Library search rather than trying to find it in the list.

One of the major things that the Library does not do that the old Real Studio control palette did is show you any subclassed controls.  Instead, the thought is that you can find any subclassed control in the Navigator and drag and drop it into the layout editor.


Properties Panel

The old Real Studio properties list was very powerful.  It let you change and and all properties via the keyboard and you never had to touch the mouse.  In Xojo, the properties list has been replaced by the Inspector.  It is not keyboard friendly so expect to use the mouse to set some of the non-text properties (checkboxes, sliders, color pickers, lock positions, popup menus, etc).

Another missing feature is the ability to use dynamic constants for certain properties.  In Real Studio you could make a dynamic constant for a color and use that constant in the properties list.  In Xojo this is impossible and to do something similar you’ll have to resort to the open event of the control.  This seems to be a huge oversight in the design of the Inspector.

The Inspector, in my opinion, is one of the big weaknesses in Xojo.  So much power and functionality was removed that I hope they really rethink their decisions.  Among some of the UI faux pas in my opinion was the use of sliders for boolean values.  They look cool (with animation!) but they don’t really add much to the product.  They take up more vertical room than a regular checkbox and thus require more vertical spacing so they don’t look crowded.  Their usage is inconsistent as well even in the Inspector.  Some boolean properties use a slider and some use checkboxes.  I’d prefer one or the other but not both.

The vertical spacing used in the Inspector makes large lists hard to deal with.  For example, the desktop Listbox control has a lot of properties and it is impossible to see the entire property list without scrolling even on a large display.  I expect this issue to be even more glaring on a laptop with limited vertical real estate.

Attributes Panel

The second part of the Inspector is the Attributes panel.  Attributes are a more advanced feature that most developers won’t use.  It has a simple interface to add attributes as well as boolean sliders to mark whether to include the object in Desktop/Web/Console builds.


One odd feature in Xojo is that the Library and Inspector cannot be open at the same time in the main Xojo window.  There is a preference setting to make them palette windows but that’s not exactly ideal for many people.  The reason I find this so distasteful is that in Real Studio I put a control on the layout and then immediately name it (we never use the default names except for labels that are never referenced in code).

To do the same thing in Xojo I have to open the Library, place the control, and then Open the Inspector.  Then I have to place my cursor in the Name field which usually requires two clicks to select the entire name and then put the new name in.

This change isn’t a huge deal but it is irritating because it changes my workflow. What I have to do now is put all my controls on the layout and then open the Inspector and rename the controls.  Like I said, it’s a simple thing but I’d love to have the ability to have the Library and Inspector be open at the same time (not in palette windows).  I’d also love to have the option to put the Library or Inspector on the left side next to the Navigator.

Panels ErrorPane

At the bottom of the Xojo IDE is a new area for panels.  These panels let you search the project, see error messages, and to show system messages.  The panes can be resized to some extent but there’s a vertical limit that can be kind of annoying.


The Find panel takes the place of the Real Studio Find dialog.  It allows you to search and replace anything defined in the scope which depends on the item selected in the Navigator.  Otherwise it is very similar to the Real Studio find and replace mechanism.  Doing find and replace in the current method requires selecting that option from the control widget.  Again, not very onerous but it is yet another mouse event.


When you compile your project or use the Check function any errors or warnings are displayed in the Errors pane.  It is displayed automatically when it is needed.  The functionality of the Errors pane is nearly identical to the Real Studio errors tab.


New in Xojo is the Messages pane that shows you any System messages your app may have generated.  This includes anything sent to the System.DebugLog which is handy.  A convenient search field lets you find specific messages quickly.

Layout Editor

The  Xojo layout editor does not have many new changes other than both Web and Desktop editors look and feel like the Real Studio Web Edition layout editor.  Despite it working there are some changes that you’ll have to get used to.


One of the more welcome changes was the addition of the Shelf where non User Interface controls, such as the Timer, or Socket controls live.  No longer do you have to figure out where to put those pesky controls.  The IDE now puts them there automatically.

Non-UI controls also included Toolbars.  Adding one to a Window places it on the Shelf.  This might be the one control I really want shown at the top of the window as a visual aid.  After all it HAS a user interface and see what it contains is sometimes important.  Not a huge thing but as someone who uses toolbars a lot this is a drag.

Inline Editors

InlineEditorLike the older Real Studio Web Edition layout editor, both the Desktop and Web layout editors for Xojo have new inline editors.  The inline editors are small editors you invoke directly on the layout that let you manipulate the control.  For example, if you place a pushbutton on a window there is a small circular button with a pencil icon on the right side.  Click that and an editor appears right next to the control allowing you to change the button caption.  More complex controls like the Listbox have more complex inline editors.

This is another instance where some functionality was taken away.  In Real Studio if you placed a pushbutton on a window and started typing, whatever you typed would become the caption.  This was a very convenient way to get things done.  In Xojo you can’t do that and you’re forced to either use the Inspector or use the Inline editor.

Adding Events

Perhaps the biggest change in the Layout Editor is how you access events to an object.  Recall that in Real Studio every event for every control/object is available at all times.  This is no longer the case in Xojo and you have to add the events you want to use.

AddEventHandlerThe mechanism for adding events is a little weird because it depends on if the control already has an event handler or not already.  If it has no event handlers yet, double clicking on the control will invoke the Add Event Handler dialog.  The dialog then displays a list of all the available events for the object.  If you need more than one event you can select one or more events by holding the modifier key or shift key to select the ones you need.

However, if you already have an event handler for the object double clicking on the control drops you down into the Code Editor for the event (which one seems to not always be clear).  To add another event you have multiple options.  The Insert toolbar, menu, or contextual menu all have Add Event Handler options.  Selecting it invokes the dialog again.

The dialog itself has some interesting features in that as you highlight events a brief description shows up on the right.  If you select multiple events (whatever the standard platform modifier keys are for list boxes) the dialog will attempt to display descriptions for all the events selected.

I see this area as being the most controversial and perhaps generating a ton of questions from those new to Xojo.  Adding and using events was always one of the most appealing things in Real Studio and that now takes extra work to use them in Xojo.  It’s not a lot of extra work but I can see it generating some questions.

In my opinion the biggest reasoning for forcing the user to add events in this fashion was because of the Navigator.  Since the Navigator list can get rather large on even small projects having every event available for every object would just make the Navigator worse.  So the obvious solution to help the Navigator was to limit the events it shows.  Voila!  Force the user to pick which events they want.

To be honest for some controls I absolutely love this decision.  Label’s are one of those controls that has 18 events that I rarely ever use.  However, some controls, like the timer have only one event and to use it I absolutely have to add that one event.  So the dilemma for Xojo going forward is to how to make this feature more useful and smarter for all of us.

Code Editor

CodeEditorThe Xojo code editor is mostly the same as the Real Studio code editor in appearance and functionality.  In reality it’s a completely rewritten editor mainly because the entire IDE is a Cocoa application (on Mac OS X, of course).  The code editor is a canvas subclass and in Cocoa applications the canvas control cannot get the same keyboard input as regular text fields.  This led to the creation of the Text Input Canvas plugin that lets Cocoa applications get the same level of keyboard information (more on this later) for non-text controls (i.e. the canvas).

The one big change in the Code Editor is that to define a new Method you absolutely must have the Inspector visible.  In Real Studio you defined the method name, parameters, scope, and return value at the top of the Code Editor.  Now those are defined in the Inspector.  Moving all this to the Inspector makes sense from a consistency standpoint but the Inspector is generally a much smaller area so now long parameter lists are cramped into a much smaller and less usable text area.

When you define a new method the Inspector shows if it’s not already shown.  The method name field is highlighted allowing you to type the new method name.  Hitting tab takes it to the Parameters text area.  Hitting tab again *should* take you to the Return type but at the time of this writing it inexplicably puts the focus in the text editor.

Moving the definition into the Inspector one of the more annoying changes.  Moving my eyes from the Navigator where I’ve decided I need a new method to the extreme right to the Inspector (or wherever it’s at as a Palette window) is a bad design.  Not only is there massive eye movement but moving the mouse from one edge of the screen to the other just seems silly (the tab control bug withstanding).

Tab Editors

Web Edition Tab editor WETabEditor

The tab editor for Web Edition is using the same tab editor used in Real Studio Web Edition.  It’s an easy editor to figure out but if you have a ton of controls it can quickly become a mess.  Otherwise, it’s exactly the same.

DesktopTabEditorDesktop Tab Editor

For many people the existing Tab Editor for Real Studio (desktop) was a capable editor.  It’s one big deficiency was that if you had to add a control at the beginning of the tab order you ended up renumbering a lot of controls.  The Web Edition tab editor doesn’t work very well in desktop since Web Edition applications have no concept of parent controls.  So Xojo takes an alternative approach by using a hierarchical list to display the contents of the window.  The user can then simply drag reorder the controls in the order they want.  Non-tabbable controls do not appear in the list.  It’s simple but it works.

Menu Editor


The Xojo menu editor has been modified to fit in the Navigator.  Besides having the menubar itself in the Navigator each individual Menu and each individual Menu Item is also in the Navigator letting you select it directly from there or through the editor itself.

Having items in the Navigator *should* make it easier to copy/paste/duplicate menu items but as I write this review that functionality is currently not working.

Database Editor

I was not a fan of the Real Studio database editor.  I recommended that you don’t use it because it led to some bad practices because it wouldn’t let you define your own auto increment primary key for a table you created.

The Xojo Database Editor is different though I still can’t say it’s improved.  It still has most of the same flaws as the Real Studio database editor.  So until Xojo, Inc. decides to get serious about the DB editor I recommend not bothering to use it.  There are much better free or inexpensive tools to manipulate your databases and I’d recommend using them rather than the Xojo Database Editor.

Constants, Enums, Structure Editors

Much like the Code Editor the constants, enums, and structures editor has changed so that the definition is forced into the Inspector.  Editing individual items then takes place in the center editor.  I have no problem with the editors in and of themselves but forcing them to use the Inspector seems like a solution waiting for a problem to fix.


The Xojo Profiler was rewritten for Xojo and now handles threads much better.  The Profiler has some nice features to make it easier to figure out what code in your app is taking the longest.

Invoking the Profiler is different than in Real Studio where it was a menu option. In Xojo it is a boolean option in the Shared Build Settings section that is reached via the Navigator

Project Formats

The file extensions in Xojo have changed to accommodate the new name change and to help avoid collisions in the future (how many times did you double click on an .rb project file in Mac OS X and it opened Xcode?) with other languages.  So now the default file extension starts with xojo and then an identifier with which type it is.

The three formats available to Xojo are Project, Binary, and XML.  If you have any valid license you can use any format.  If you are using the IDE without a license you can only save in the binary format (though read any of them).

Xojo Project (text)

The new default project type is the Xojo Project file type.  It is the Real Studio version control format and a file is created on disk for every object in your project.  This is awesome for version control systems that scan the files for changes and then save ONLY the changes it detects.

Xojo Binary

The Xojo Binary format is similar to the old Real Studio binary format.  Many people use this format for the ease in transporting projects.

Xojo XML

The Xojo XML format is similar to the old Real Studio xml format.

Cocoa Framework

The Cocoa framework is finally done and the beta status is ready to be taken off the build option.  Why am I so confident of this?  Because there is somewhere in the neighborhood of 125 Cocoa bugs that have been fixed for Release 1 and Xojo itself is a Cocoa application when running on Mac OS X.  Building for Carbon is still an option but don’t expect a whole lot of fixes for Carbon going forward and part of that is simply because Apple is not fixing many Carbon bugs.  Cocoa is the wave of the future so you should really start using it and, to be honest, in my testing it’s been solid.  I should note that the carbon build option isn’t going away anytime soon but the clock is ticking.

Not everything is a perfect in-place upgrade.  A new runtime exception has been added to Xojo for any thread (other than the main thread) that accesses a user interface object.  The new UIException is thrown whenever you try to access literally any part of the UI.  Trying to create menu items at startup in a thread?  You can no longer simply create new MenuItem objects and add them to a menu because it will generate the UI exception.  You can generate the exception even by simply accessing the properties of a control at runtime.

For years Real Software (now Xojo, Inc.) said that doing so wasn’t safe but most of us did it anyway.  Now Xojo enforces the limitation.  The workaround is to add events to a thread object which fire timers.  The timer action events fire on the main thread letting you do your UI work there.  There is a new example project under Projects -> Desktop -> Threading -> Tasks that you should probably take a look at.


The REALSQLDatabase class has always really used SQLite in the background.  However, based on decisions that were made many years ago, the REALSQLDatabase class did a number of things that were less than ideal.  For one, it inserted the rowid into many of the SQL queries.  While most queries never noticed the addition there were occasions where it really messed up the underlying query.

In Xojo 2013 Release 1 the REALSQLDatabase has been deprecated and a new SQLiteDatabase class has been added.  The new class no longer inserts the RowID into queries for you.  If you were relying upon this (I highly recommend you do NOT) you can insert it yourself.

Another change in the new class is that it no longer has the AutoCommit property.  Xojo will treat all database actions as an implicit transaction which means that the commit will happen automatically unless the user specifically starts a new transaction.

Also new in the SQLiteDatabase class is the ability to backup your SQLite database while it is open.  This is a convenient way back up your database during runtime without having to close connections and copying the file.  While the backup is occurring it will block other database operations but otherwise it won’t throw an error.

Remote Debuggers


Xojo comes with an updated Remote Debugger (GUI) application.  It is now at version 2.0 and has the same functionality is the Real Studio version.


New in Xojo is a Remote Debugger Console application.  The new console debugger can be used to remote debug console and Web Edition applications on headless servers.  In my initial testing the UserGuides aren’t quite as helpful as they could be on how to setup and use it in conjunction with Xojo.  I’m sure the documentation will get better but in the meantime good luck in getting this working!

New Licensing

If you have not heard, Xojo is now free until you want to build a final executable.  Then you need a license for the what you’re building for.  I won’t go into much detail on this since it’s been documented at http://www.realsoftwareblog.com/2013/04/coming-soon-new-pricing-recap.html

For many developers their license costs will go down.  For those that are current Enterprise owners the price will most likely go up a little.

Control Sets

One thing that’s changed in Xojo is that Control Arrays are replaced with Control Sets.  They are really the same thing but the naming threw people off (myself included for many years) because we heard ‘array’ so we expected that we could use them like a normal code array.  Since you couldn’t the switch was made to rename them control sets.

The change has caused a few minor changes to the Inspector so that you can tell Xojo which control set it’s a part of and what its index is in the set.  Naming a 2nd control the same name as another control invokes a dialog asking if you want to create a control set.

Plugin Format

Xojo plugins are now really zip files.  The old format used the considerably slower Virtual Volume.  This speeds up the startup of Xojo drastically.  You can use old style .rbx and new style .xojo_plugin at the same time.  Monkeybread users will want to migrate to the newer xojo plugins to take care of incompatibilities.  Most of the major plugin vendors have migrated to the new format.

Text Input Canvas Plugin

Cocoa is a different beast in many ways when it comes to text and keyboard handling.  Carbon applications give you a bunch of additional information for free as part of Apple Text Services that gives you (for free) special character handling.  Unfortunately in Cocoa this mechanism is completely gone.

We’ve already talked about how the Code Editor is a special canvas subclass.  It was suffering from the lack of information and there was no way around it.  Xojo Inc has produced a new open source plugin that allows you get all of the events you need to capture special text handling.  It does this by introducing a number of new events that your canvas subclass will have to take care of.

We, BKeeney Software, have been beta testing the Text Input Canvas plugin in the Formatted Text Control with great success.  Once Xojo Inc. releases the plugin we will release version 3.1 of the FTC.  It will also prove to be an ideal example of how to parse the new events and commands that the plugin requires and uses.  Expect this plugin to be released soon after the Xojo release.

One Click Hosting

Xojo Inc announced the June 4th release date at the Xojo Developer Conference.  This was roughly 24 hours before their web server got hacked.  The hack caused them some delay in getting those services back online and forced their migration to their new Xojo Cloud server.  Delaying the release again was out of the question so the One Click hosting has been delayed and it will enter beta at some point after Xojo Release 1.


Xojo has completely new example projects and completely new documentation. All of the example projects have been rewritten to use the file formats as well as the new Xojo classes.  The examples have also been reorganized to make things easier to find.

The documentation for Xojo is quite impressive.  The standard download package has 9 PDF guides ranging from QuickStart guides for Desktop and Web, to Tutorials for Desktop and Wb, and UserGuides for Development, Framework, Fundamentals, and UserInterface.  In addition to all of that Xojo comes with a PDF and iBooks version of the Upgrade Guide.

If you read no other documentation about Xojo I highly recommend reading this book.  It contains more in-depth description of many of the items I’ve talked about today and contains additional screenshots.


There are many, many reasons to like Xojo.  A lot of thought and care has gone into many of the design changes.  There are some areas of improvement such as keyboard handling and some workflow issues that they’ll have to change to satisfy Real Studio old-timers such as myself.

For Windows and Linux users there is less to be happy with.  The UI is identical on those platforms (minus animations) and looks even more foreign on those platforms.  Linux and Windows users should not expect many changes to the frameworks for those platforms.  This release all about Cocoa and the new UI.

Xojo Inc. has put a lot of time and effort into this release.  I admit that I am, and will continue to be, critical of the product.  It is, after all, what supports me and my employees.  I will say this though:  Xojo is much better than I had feared but not as good as I had hoped.  For my own consulting company all new projects going forward are using Xojo.  Existing projects will move forward under Carbon in Xojo unless they use no threads in which case they’ll be converted to Cocoa.

Please let me know your thoughts about Xojo!