Xojo 2016 Release 2

Last week Xojo 2016 Release 2 was unleashed to the masses.  There are a lot of changes and tweaks in this version and if you are creating web or iOS applications there is a lot of like about this release.  There are also a myriad of changes and enhancements that should satisfy most developers.

iOS Stuff

The biggest changes in R2 is for iOS and these are things that developers have been requesting since its initial release.  Support for iOS 7 has been dropped because its market share is less than 20% and the minimum required version is now iOS 8.  This also means that Xcode 7 or Xcode 8 needs to be installed.

The Xojo engineers added iOSScrollableArea which allows you to view and display content that is larger than the view.  This is a very welcome addition and is worth the upgrade for this feature alone.

R2 also adds the iOSLocation class that allows your application to request location coordinates as well as get updates from the device.  Once your application gets permission to access the device location you receive changes via the LocationChanged event that gives you latitude, longitude, altitude, course and speed parameters.  An Accuracy property lets you change the desired accuracy.  In addition to iOSLocation Xojo has added the iOSMotion class that allows developers to access the accelerometer and gyroscope.

iOSTable was arguably the most useful and least powerful control in iOS for Xojo and this release definitely gives it some love.  You can now embed controls in the cells of iOSTable by using the iOSCustomTableCell class.  This allows you to create some very rich and powerful UI that lives in the cell of an iOSTable.  I guess the best equivalent in desktop and web terms is that the iOSCustomTableCell is a specialized ContainerControl you can put into an iOSTable cell.  I’m looking forward to using this.

They’ve also added support for Row Actions in the iOSTable.  The new ActionsForRow event passes in the section and row and you have to supply the iOSTableRowAction array.  The iOSTableRowAction has a title, an Auto tag and a Style.  The style can be either Normal or Destructive with Destructive changing the background of the Action to red (does this ever vary? – not sure).

The new iOSSharingPanel allows you to share pictures, text and URL’s with any registered system service or app.  That’s a fancy way of saying you can share this data between applications.  It’s the iOS version of the clipboard available to desktop applications.

The iOSPicturePicker class allows you to select images on the device or take pictures with the camera.

To avoid confusion for users, the old SQLiteDatabase class for iOS has been renamed iOSSQLiteDatabase.  The corresponding recordset class is now named iOSSQLiteRecordSet.

Non-IOS stuff

The Web framework is now HiDPI capable.  It works similarly as desktop apps in that it queries the browser for the scaling factor.  Then, the application serves up the proper image if it can.  You can change how this works by changing the Supports HiDPI in the Shared Build Settings.

In Windows there are a number of significant HiDPI changes that make it work better in Windows 8.1 and 10.  Perhaps the biggest Windows change is that Xojo.Net.HTTPSocket is no longer much slower than HTTPSecureSocket.  I have not had a chance to look at this one in detail yet so if you’ve had success or failure with it, please leave a comment below.

Always check the release notes that are in every release.  I’m just hitting the highlights out of hundreds of line items and you never know what might be there that affects your application.

As with any new release it’s better to test your project against it before releasing it into the wild.  In my own testing I had some instability with converting an old web project (started around the very first public beta of Web Edition) to use HiDPI graphics.  This involved adding an ImageSet and adding the 1x and 2x graphics, deleting the old graphic, and then fixing it in all locations in the project.  I was able to crash the IDE but all of the crashes were different and, of course, none of it was reproducible.

The Future

The 800 pound gorilla in the room is a 64 bit IDE and 64 bit debugging.  Things like XojoScript are holding back the IDE from being 64 bit.  I would also imagine that not having an integrated debugger available in 64 bit is holding back that as well.  I know we are avoiding releasing some 64 bit projects because of these limitations. We’ve also been playing around with the Raspberry Pi and it’s definitely not very useful without the debugger.

We need the 64 bit debugger.  Let’s hope that R3 provides us with some relief in that area!

How has your experience been with R2 so far?

Xojo 2016 Release 1.1

Xojo 2016 Release 1.1 hit the web today and this version should be the one you’re using from now on.  This dot release fixes a number of critical and important things.

First off, web app compile times just got much better.  Building a 64 bit Linux web application went from five minutes in 2016 R1 to just three minutes in 2016 R1.1 (both versions had to recompile the plugins so take two minutes off that for an average time). This is a marvelous and unexpected surprise in R1.1.

The Web Page Layout editor that was a dog in R1 is much improved.  A complex web page with multiple containers and controls is now nearly flawless when dragging controls around on the page.  This one feature alone is the worth upgrading to R1.1.

The MySQL plugin no longer crashes when a closing the database connection.

BMP’s with a mask dragged into a Linux project long longer throws an out of bounds exception when the app is launched.  Xojo.Net.HTTPSocket was also updated.

In Windows, the SaveAsDialog no longer returns the wrong name if anything in the file path has a period in it.  Xojo.Crypto.RSAGeneratePair no longer crashes.  The new Language Reference no longer has high CPU usage and the Windows IDE no longer crashes when a remote debug app quits.

Besides the web page editor, the IDE also received a few fixes.  Perhaps most important is that searching the project no longer results in a crash for some developers.

Read about all of the R1.1 changes in the release notes.

All-in-all R1.1 is a welcome version and I recommend that you update to it immediately.  What do you think?

Xojo 2016 Release 1

Xojo 2016 Release 1 was released today.  This much anticipated version is all about Retina and HiDPI display support.  In addition to that, there are, as always, the usual mix of new features and bug fixes.  Let’s get to it!

The IDE is Retina Aware

The IDE itself is now Retina capable and all of the icons and images used in the IDE have been replaced with high resolution images.  On my 27 inch 5k iMac it’s quite a noticeable difference to my aging eyes: everything is very sharp.  As with many apps once you start using the high resolution version it’s hard to go back to a lower resolution.

Before you jump into this version you might want to do some testing.  On relatively new iMac the Web Layout Editor is very slow.  So slow as to be almost unusable.  This only happens on existing projects since new projects seem to work just fine.  Perhaps it’s a combination of project size and/or web page complexity or number of Web Containers.  I really don’t know but I’ve submitted a Feedback report showing the symptom and an application sample from Activity Monitor.

Your Apps Can Be Retina Aware

In the last Xojo version we were introduced to ImageSets and that feature is now more useful in 2016 Release 1.  The ImageSet allows you to add a normal sized image (1x), a 2x image, and also a 3x image.  Mac OS X only uses the 1x and 2x images but some Windows 10 resolutions will use the 3x image.

HiDPI support for Windows is officially beta and I believe that’s mostly because the various versions of Windows that Xojo supports all do HiDPI slightly different.   Currently Xojo does not support Window 10’s per-display scale factor and will use the scale factor of the screen it was launched on.  TextArea’s only display in large size, the HTMLViewer and MediaPlayer is not scaled, BevelButtons don’t display, and Image Set Icons do not appear correctly in toolbars.  Obviously this is less than ideal for Windows applications and you probably don’t want to release a Windows app with this set.

With Retina/HiDPI support is a new Application shared property called SupportHiDPI.  When set to true, Xojo will build your application with Retina and HiDPI awareness.  When set to false it will build apps that worked the same was as previous builds.  Sadly, this property cannot be changed at runtime because it would make enabling it for Mac OS X a no brainer but leaving Windows as is.

As you can imagine, Retina/HiDPI changes a number of important things.  The Picture class has a new constructor that can take one or more bitmaps in addition to its size.  All bitmaps must have the same aspect ratio or an invalid argument exception is generated.  One question that I’ve not explored for myself is how exact this ratio must match.  What is the precision on this check?

The graphics object now has a ScaleX and ScaleY property.  For pictures the scaleX/Y are always set to 1, but a graphics object passed in from the paint event might have a ScaleX/Y set to 2 on a Retina display.  Graphics.Pixel is now deprecated (NOT REMOVED).

Windows have a couple of changes too.  There is a new event ScaleFactorChanged on Mac OS X that is an indicator that all graphics for that Window should be invalidated.  A read only ScaleFactor tells you what the scale factor is for this window.  The Canvas object has a similar ScaleFactorChanged event on Mac OS X as well.

Local Language Reference

Retina is not the only new thing in R1.  The Local Language Reference has been revamped again and if you are a Dash user you’ll notice that it shares much of the same look and feel.  Searching for an item in the Language Reference, in my opinion, is considerably easier in this new version and I find I like it better than the online version.  Besides being able to search for any event, property, class, enum, etc the local language reference allows you to go back through your search history rather quickly.

Web Framework Changes

The web framework received a number of important changes.  Perhaps the biggest and most important to web users are that WebStyles have changes their implementation.  The change notes say “User defined WebStyles now have more specificity than framework applied styles.” which I have been lead to believe means that WebStyles now work properly in all cases as there were fringe cases where styles were either ignored or improperly applied.  During the beta cycle Xojo asked us to test web apps to make sure nothing broke.  In my testing I didn’t see any issues.

The connection type of a web app can now be set with a command line option.  The WebListBox received some love too.

Miscellaneous Fixes

  • Build times have been improved.
  • Xojo.net.httpsocket now works in Mac OS X console and web applications.
  • A memory leak in NSWindow was fixed in the Cocoa framework.
  • The FileTypes editor has received a number of bug fixes and changes.
  • 40 changes to the documentation and examples.


With all of this work on Retina/HiDPI applications for Release 1 I am disappointed at the lack of project examples for HiDPI and Retina.  Sure, the SupportHiDPI is an easy thing to do, but for many of our applications that create images on the fly we are only left with some fairly vague instructions.  A Xojo Blog posted today http://blog.xojo.com/a-journey-of-a-thousand-pixels might be your best bet in understanding some of these changes in more detail but even I scratched my head with some of the implementation details.  Actual example code that show the practical implications of Retina/HiDPI and creating images would have been very welcome.

I’m relatively happy with 2016 Release 1 though not without some reservations.  Since the number of Windows controls in HiDPI that don’t scale properly is fairly large it’s not ideal that you can’t turn off HiDPI for Windows but keep Retina on for Mac OS X.  Sure, you can always do two builds but it’s not an automated option.  Performance issues with the Web Page Editor is also troubling and perhaps this means there’s a dot release in our near future.

There are quite a few things on the horizon that Xojo needs to tackle.  Full debugging in 64 bit and a 64 bit IDE is perhaps the biggest one and the HiDPI stuff is surely a distraction from that important requirement.  This beta cycle was really long and it makes you wonder how much their schedule has shifted just to get HiDPI (mostly) working with some obvious work still to do.

What are your thoughts on Release 1?

Xojo 2015 R4

Xojo 2015 Release 4 hit the internet today.  The fourth release of Xojo this year is full of bug fixes and only has a few new items.  I’d recommend using this release as the bug fixes are substantial.

Let’s get what’s NOT in this release out of the way.  This release was initially supposed to be about getting Retina and HiDPI capabilities in the IDE and in our applications.  It was determined that there just wasn’t enough time before the end of the year to get it done.  It’s disappointing to not get these new capabilities but I’d rather they be done right than Xojo giving us a half-assed feature that no one is really happy with.

This release also does not complete the 64-bit work started in 2015 Release 3.  We still cannot use the Remote Debugger to live debug 64-bit applications and there are still major gaps in the capabilities between 32-bit and 64-bit applications.  A full list is here:  http://developer.xojo.com/64-bit-guidelines

Changes and Fixes

What this release does is fix over one hundred compiler, framework, database, and IDE bugs.  There a number of 64-bit bugs that have been squashed that were causing linking errors or outright crashes when compiling 64-bit applications.

For the framework there are a couple of high profile fixes that are welcome.  XML Exceptions no longer ‘skip’ exception handlers.  I know this has been troublesome for many developers.  An issue with the new Xojo.IO.Folderitem class has been fixed on Cocoa that would cause crashing when a FolderItem object was put in a tag, for example.

The Web framework received

some bug fixes as well.  Some of the more notable:  WebSessions no longer quit when moving from network to network.  WebPicture’s no longer return nil when defined from a FolderItem and the WebPicture no longer uses twice the memory when the image is in the project file.  The web framework now recognizes the Epiphany web browser on Raspberry Pi.

The WebDragItem now has the Origin X and Y values that indicate the X and Y coordinates of the Sender web control where the drag began.  I haven’t tried this out yet, but this should make some things (like a web based designer) a little easier to create.

The MSSQLServer Prepared Statement no longer returns a nil and should allow developers to use this safer method of using Xojo with Microsoft SQL Server database servers.  The ODBC Database plugin also got an update so it no longer crashes when retrieving large SQL columns.

The IDE has dozens of bug fixes.  Most of them pretty minor but they add up.  Among the more notable fixes:  AutoComplete has had extensive work so that control arrays and structures should work.   Private methods and properties now show in AutoComplete as expected (now, only when in scope).

The Syntax Help Area (at the bottom of the Code Editor) is now scrollable  when the content does not fit the preexisting area.    This area will also show the description, if there is one, in addition to the signature.

The Interface dialog now resizes itself to 75% of the window height.  If you make it larger it will reopen at that size (or the limits of the window).

Filtering in the Navigator now shows results ordered on how closely they match the string based on the Levenshtein distance of the match.  So if you don’t quite get the name right you might still get results instead of requiring an exact match.

New Stuff

Despite this being a mostly bug fix release there are a couple of new goodies that might make your day.  The first is that MySQLCommunityServer now has a SecureAuth property which allows users to authenticate using old password hashes.

The Graphics class for desktop apps has a new property, called CharacterSpacing, that allows you to change the percentage spacing between characters.  You can use both positive and negative values.

Web Text controls now have a TextAlign property.  This should simplify web projects as you no longer do have to duplicate a WebStyle and change the alignment simply to change the text alignment for a single control.  You can still do that but this is a new way to eliminate that extra work.

In some preparation for Retina, Image Sets are now available.  Use the Insert Menu and select Image.  In the Image Set editor that are now 3 thumbnails for the set for normal size, double size, and triple size.  But since this release doesn’t include Retina support this feature is of limited usefulness – for now.

What might be the biggest news of the release is the addition of the CGFloat data type.  This temporary datatype aliases to a Single in 32-bit builds and a Double in 64-bit builds.  This should make fixing some the common libraries (think MacOSLib) easier since we can make one variable that will work for both build types.  Xojo has said that once 64-bit iOS and OS X builds are ONLY 64-bit the CGFloat data type will be deprecated.

Future Releases

I’m a big fan of these mostly bug fix releases.  In a product that changes so much and so quickly (at times), these bug fixes releases allow us to take a deep breath and not worry too much about using this release.  We worry about the big releases because of the shear amount of changes involved and the amount of testing required with our applications.

So what do we have to look forward to in 2016?  Presumably, 2016 will see a full compliment of Retina and HiDPI support since Xojo publicly pulled it from this release.  I would also expect the 64-bit journey to continue with hopefully the IDE becoming 64-bit which means that XojoScript, Windows version and icon information work, and the grandaddy of them all, Remote Debugging work in 64-bit.

I hope we get a Remote Debugger for Raspberry Pi simply because that will make life easier on that platform too.  I’m not sure what else we really need for Raspberry Pi.  What have I forgotten?

I would expect the IDE to get some level of redesign.  Many people, including myself, are unhappy with the workflow in Xojo and think it’s slower to use than Real Studio.  I know of several large customers that have stuck with Real Studio rather than migrate their projects to Xojo simply because of the IDE workflow issues.  Personally I’m happy that Xojo plans to address some of those issues.

I expect the iOS framework to grow with new controls and capabilities.  I also expect the new Xojo framework to keep growing (TCP Socket perhaps being the biggest need) and getting more attention to eliminate some of the cross platform bugs in it (looking at you HTTPSocket).

Will 2016 be the year that the desktop or web frameworks gets rewritten for the Xojo framework?  Perhaps, but Xojo isn’t saying much.  With XDC now in October we won’t get much of a hint of future plans until then, or until we see it in a beta cycle.

I know that Android support is at the top of the wish list in Feedback.  I do NOT see it in 2016 simply because it’s yet another platform.  Unless they’ve already started the work on it (which is always possible and we haven’t noticed it) I expect it to take at least 18 months (more likely two years) for an Android beta release.  And even then, how long until it’s really usable?

So what is your take on this release?  Good, bad, or meh?  What are you most looking forward to in 2016 from Xojo?

Xojo 64-Bit Apps and Raspberry Pi

Xojo 2015 Release 3 is now publicly available.  This release is, by far, the biggest Xojo release in many years – if not ever.  All targets can now be built for 64-bit and also for Raspberry Pi (32-bit ARM).

Building your application for 64-bit in Xojo is as simple as going to the build settings for each platform (Mac OS X, Windows, Linux) and setting the Architecture to 64-bit.  On Linux builds in addition to the 64-bit option there’s also the ARM 32-bit option to build for Raspberry Pi.  It really is that simple.

All this is really good news because Xojo put a lot of time and effort to get the 64-bit compiler working.  They’ve obviously been working on 64-bit much longer than just this release period but to add twelve new targets (Mac OS X 64-bit desktop, console, web, Windows 64-bit desktop, console, web, and Linux 64-bit desktop, console, web, and Linux ARM desktop, web and console) is impressive, to say the least.

Raspberry Pi support is better than initially announced at XDC 2015.  Initially we were told that Xojo would only support console applications for the Raspberry Pi.  Instead, we have the ability to not only create console applications but also desktop and web applications for Linux ARM.

I’ve taken some random web and desktop projects and ran them on the Raspberry Pi with few to no issues.  The only thing I’ve not been able to get working is cgi web applications even though I installed Apache (I’m sure it’s simply a matter of getting the configuration correct).

One of the cool things about the Pi is that you can use GPIO and create all kinds of cool projects with switches, LED’s, and sensors of all types.  In the examples that come with R3, look in Platform-Specific/Linux/Raspberry Pi/ and you’ll see four projects that make use of the Wiring Pi library.

If you want to dive into Xojo and Raspberry Pi I highly recommend you take a look at the Xojo GPIO page on the Einhugur blog at https://einhugur.com/blog/index.php/xojo-gpio/.

If that wasn’t enough for one release, Xojo didn’t stop development on other parts of the IDE.  Web applications can now use drag and drop between objects on a WebPage.  They added a new AcceptingConnections property that allows you to start/stop a web app from accepting connections.  Standalone web apps now use TLSv1.2

There’s some new features in iOS too.  iOSLabel has new clipping modes that you can use instead of wrapping.  iOS now has container controls which should allow for some really complex user interface designs.  The iOS advanced tab in Build Settings now gives developers the ability to modify the Entitlements of built apps.

The desktop app FileTypes Editor is completely revamped and now allows developers to specify UTI’s for Windows and Linux too.  The new editor also lets you know if the icon set is complete.

A few important IDE bugs have been fixed.  If you delete an object that has open tabs those tabs are closed.  The grab handles on Layout Editor objects are now inline with the control frames than outset slightly.  These are annoying little things and I’m glad they’ve fixed.

Moving your own applications to 64-bit seems to take two routes.  One, it will just work and you’re on your way; or two you’ll have some work to do.  This seems to depend entirely on if you’re using plugins and libraries.  MonkeyBread Software and Einhugur have 64 bit versions of their plugins ready to go so check with them for 64-bit compatible versions.  MacOSLib may cause some issues and while I know the developers have been updating it I don’t see anything on their GitHub site saying they’re compatible yet.  Windows Functionality Suite users out of luck since it was made before structures were available in Xojo so if you’re using any of those classes you’ll have to find alternatives.

I would expect a few things about 64 bit to come to light now that it’s released to a bigger audience.  While I can’t confirm a dot release is coming I expect one to fix anything major to come up in the next week or so.

Everything is not yet perfect for 64-bit in the R3 release.  For one, the debugger doesn’t work in 64-bit applications yet.  Until that’s released you’ll need to debug the old fashioned way using console messages and log files doing full builds.  You cannot do remote debugging for ARM targets either.

A few other items are unavailable for R3.  XojoScript is unavailable for 64-bit or ARM targets.  You cannot build 64-bit Mac OS X apps from Windows or Linux.  Icons are not preserved in Windows 64-bit apps.  Tooltips class and tooltips on the ListBox do not work on Mac OS X 64-bit.

The Xojo IDE itself is not 64-bit.  I don’t think this is a huge deal yet but it’s also impressive that they were able to get 64 builds from a 32 bit application.

This release is massive and impressive with 64-bit builds and Linux ARM as well as over 300 changes and bug fixes should make everyone happy for a while.  Xojo should be congratulated for their hard work.

What did I miss?  What are you happy or disappointed with?

XDC Notes:  Compiler Notes AND Exception Line Numbers

So far I’ve written a couple of posts about information gleaned from the XDC keynote address last week.  One session that revealed some additional information was Joe Ranieri’s Compiler session.

Joe started off by talking about what’s happened to the compiler in the past year.  The list is pretty impressive since that includes iOS (32 bit AND 64 bit), 64 bit for Mac, Windows, and Linux, as well as adding the new framework, and adding better compiler error messages.

He spent some time explaining why the Using and Global keywords came about and how they are used.  It’s interesting that you can mix and match the two frameworks and how that might be desirable.

Iterators were next up in the presentation.  Iterators allow our classes to be used with For Each loops and Joe said that iterators are generally more efficient than alternate approaches.  Two interfaces are available Xojo.Core.Iterator and Xojo.Core.Iterable.  A good example of the new interfaces are in the Xojo.Core.Dictionary class.

The new Text datatype is the attempt to solve the String datatype deficiencies.  Strings could be text or a bucket of bytes which led to issues with encoding.  Text is always a valid textual representation and is a series of Unicode code points (a way to think of this is an array of characters that might be ASCII or a valid Unicode character- either way you, the developer, don’t need to care).  When converting to Text you always give it the Encoding you want so it’s never in question.  One nice feature of Text is that you can convert to and from a String with no penalty.

The New Auto datatype is the replacement for Variant.  Auto’s perform NO conversion of data which led to sometimes subtle issues with Variant as it would gladly convert from datatype to datatype regardless if it made sense or not.  Auto will only do conversions that the compiler would (such as doubles and integers) but raise exceptions when it comes across something it can’t do (like strings to integer and visa versa).  Auto preserves type information exactly so you can use Introspection to determine the type.

New for 2015 R3 is more 64 bit targets.  This includes GUI projects on Windows and Mac OS X, console and web projects on Linux, Windows, and Mac OS X.  Porting, for most of us, should be straightforward.  However, there are a number of problems we’ll face.  Among them are Declares, Integer size assumptions, and Plugins.

A new 64 bit aware plugin SDK is due out soon and Christian Schmitz from Monkeybread was showing off his plugins running in 64 bit apps with no issues (it’s my understanding it was NOT using the new SDK so I’m sure he’s got some work to).  The new SDK is entirely C based and the overloaded C++ functions are going away.  Most of the long deprecated functions are doing away too.

Declares will be a problem, though.  Of particular note is the Windows Functionality Suite.  It won’t work in 64 bit and you’ll have to find replacements for those things you use.  Mac OS Lib is in better shape but needs some updating too.

Structures need to be updated for 64 bit apps to.  The default structure alignment of 1 means it puts each field right after each other and this is wrong for 64 bit apps.  If you use the structure alignment of 0 it will align the structure ‘naturally’ which matches was C does.  I’ll be honest, this was interesting news but way above my pay grade in understanding.  Talk to Joe if you have questions on the implications of this change.

Also new in R3 is customizable array sorting.  Currently we can do this using SortWith but now we’ll be able to pass in a delegate.  Joe really seemed pleased about this addition but I think the implications won’t be immediately noticed by the community.  I for one don’t remember the last time I had to sort an array since we generally load arrays sorted in the order we want later.  You might find this useful.

Joe wrapped up his talk with some roadmap items.  For R3 the IDE debugger is still 32 bit.  Obviously it needs to be 64 bit and that will happen.  The better compiler error messages initiative will continue as well as Xojo-specific compiler optimizations.

Perhaps the biggest bombshell that came out of the roadmap portion was exception line number information!  This means that we should be able to get information on which line of code caused the exception.  I believe at this point several people clapped as determining which line of cause caused an exception can be difficult to determine.

I followed up with Joe after the session and while it’s not finalized, here are the plans.  The compiler will spit out two files on the build.  The first is the application and the second debug information.  When an exception is called there will be a binary blob that can be saved and sent to the developer.  There will be a tool included with the IDE that takes that blob and can show you the original line of code that caused the issue.  AND it will show you the stack like the debugger does now.  It will not have any variable or argument information.

Regardless, this is a feature that people have been requesting for years.  This should lead to better error reporting and hopefully better programs!

The compiler session was the only Xojo led session, that I attended, that had any sort of roadmap information presented (with the exception of the Keynote).  It was informative and was a wealth of information.  This session gets a five start review (except for the purple code against the black background – sorry Joe).

See anything that gives you hope?  Anything makes you want to mope?

Xojo 2015 Release 2

Xojo Release 2 went public this week.  This release is a typical mishmash of new features and bug fixes.  So let’s dig into it!


The DatePicker was added to iOS.  This is a most welcome addition and let’s you switch between Time, Date, Date and Time, and Countdown Timer.  There’s still no generic data picker which is a shame.

The Launch Images and App Icons folders for iOS has now been replaced with an editor that allows you to drag and drop images into it.  If the image isn’t the appropriate size for the selected image a message appears saying what the dimensions of the image is and that it will be scaled to fit.

[Edit]   One thing I forgot (because I didn’t see them in the release notes) was that build times are much better in R2.  From comments I’ve seen it may be an order of magnitude faster.

Web Apps

If you are using the HandleSpecialURL or HandleURL the RequestHeaders now has a Secure property telling you if the request came in over a secure channel.  If you are using SSL Certificates they can be specified on the command line.  Another new web feature is the ability to set the HTTPOnly property attribute in the Session.Cookie.Set method.  This should work as a preventative measure against cross site scripting attacks against Xojo web apps.

New Framework

The new framework is making its way to more and more of the overall package.  The Xojo.Data, Xojo.Crypto, and Xojo.IO.Folderitem are now available for all targets and platforms.  The Xojo.Data namespace includes the ability to read/write JSON (no work on XML yet).  The Xojo.Crypto framework gives you access to MD5, RSAEncrypt/Decrypt, RSASign, RSASignVerify, SHA1, SHA256 and SHA512 hash methods.  Xojo.IO.Folderitem gives  you file handling.

Xojo.Net.HTTPSocket now works for all platforms (except Xojo Cloud).  It should be noted that HTTPSocket is now ONLY asynchronous.  No longer can you wait for the response but now you have to use the events from the socket.  This is really a better way of using the HTTPSocket but if you’ve been using it in the old framework synchronously you’ll need to adjust your code accordingly.

[Edit] The new HTTPSocket supports HTTP 1.1, automatically supports proxies on all platforms, and performs proper certificate validation.  It also no longer performs polling on the socket so it should be have significantly lower CPU usage.

The Xojo.Core.Timer now works properly on Mac OS X 10.7 and 10.8.  Apparently it didn’t work properly in older versions of Mac OS X.


For many, the recent addition of the Windows ICU DLL was a major setback as they were quite large.  You’ll be happy to know that they’re now statically linking them and removed the unused portion of the libraries so the built package is now considerably smaller.

The IDE receive a large number of bug fixes including a couple of memory leaks.  They also fixed how deleting items works and how the focus works when switching between tabs with the Code Editor displaying.

According to the release notes there are 147 total items that were changed in Release 2.  This number seems a little low in comparison to some previous releases.  Given the short period between the R1 release and XDC I think this makes sense and the engineers have a lot of work to do in getting ready for XDC.

I did not get as much of a chance to run the beta as I usually do but there hasn’t been a lot of chatter on the forums about issues either.  What little I did with the beta was solid and this looks to be a decent release.

Have any comments about this release?

LiveCode vs Xojo

I have been a Xojo developer for many years and I make a decent living at it.  That doesn’t mean, however, that I don’t look around at other development environments every now and then.  I do this because it makes good business sense to keep my options open.  This week I looked at LiveCode after a reader asked me to.

LiveCode (formerly called “Revolution”) is a unique development environment that has been around since 2001.  It was inspired by HyperCard and due to its lineage it uses a Card and Stack metaphor to represent windows, objects, and applications.  To put it more in Xojo terms you can think of a window as being a Card and the entire application as a Stack (of cards).  Dialogs and other objects can then be sub-stacks.  LiveCode can make Mac OS X, Windows, and Linux desktop applications, cgi-like web apps, and mobile apps for iOS and Android.

Its scripting is a natural English-like programming language that presumably makes it easy for casual programmers to get started.  Another interesting feature is that there is very little difference between ‘development mode’ and ‘debugging mode’ and switching between the two is literally just a button.  This means that you can run LiveCode commands practically at any time without the need to compile the application first.

The IDE has a variety of windows.  The Application Browser shows you all of the objects in the stack and lets you open each card into an editor.  The editors let you put controls on the Card (layout) and each card and UI object has a number of Messages that are similar to Xojo events.  LiveCode does not have an all-in-one window like most other IDE’s.  At first, I found the individual windows to be refreshing but after I while I found that I was fighting with background application windows.  I’m sure this is something that becomes more natural with usage but I had issues with it.  I’ve always wondered if Xojo’s all-in-one window IDE approach was really the ‘best’ approach to a development environment and now I see that I prefer it as it eliminates the distractions of other windows.  Also, Eclipse, Visual Studio, Xcode and Xojo all have all-in-one IDE’s so I this it safe to assume that most developers are comfortable with this style.  You may find LiveCode strange if coming from an all-in-one IDE.

The LiveCode scripting language definitely takes some time to get used to.  The natural English syntax seems inviting but after 30+ years of coding in various languages I found it frustrating.  It’s wordy and not exceptionally compact in its meaning.  If you don’t already have any programming experience this might be good for you.  If you’re coming from a different language you might be as frustrated as I was.

Xojo events are relatively easy to find and implement.  You simply right-click on an object either in the Navigator or in the Layout Editor and add Events to the object and it’s added into the code waiting for you to add your own code to it.  The object messages in LiveCode are not so easy to figure out, in my opinion.  To figure out the events I had to go into the documentation (which was decent, in my opinion), and had to look them up and then type them into the Script Editor.  I’m sure with a little time and practice I would pick up the messages that I use most often, but it is a hindrance to picking up the language.

LiveCode Dictionary

LiveCode API Dictionary


The Xojo Code Editor has a pretty good auto complete.  Auto complete means that when you start typing, say “SQLite”, and if there are either language keyword matches or variable matches the eclipses (…) is shown and if you hit the tab key a list of available properties and methods are shown to you in their proper context.  This makes discoverability much easier.  LiveCode has no auto complete in their Script Editor which means you have to look up the commands before you start typing and you won’t know if they’re correct until you run the project.

LiveCode has objects but they don’t have the same Object Oriented nature as Xojo.  In Xojo you create an instance of the object and then get/set a property or call a method using the dot notation.  Thus opening a database in Xojo means creating a new instance of the Database, setting a FolderItem property on that object.  Then calling the CreateDatabaseFile method on that same object and it returns a true or false to indicate success or failure.  All of that revolving around the same object (database).  The same thing in LiveCode requires less coding steps but there is no dot notation and it’s definitely more procedure driven.  Each method is its own call – not part of an object – and means that you’ll spend more time looking at documentation to discover them.  I feel that Xojo’s discoverability is superior to LiveCode.

LiveCode is not a strictly typecast language meaning you can use a variable anywhere at any time.  This means that writing scripts can be very quick but it also means that introducing errors is easy and with larger projects it might be hard to find errors.  Xojo, on the other hand, is strictly typecast and the compiler will tell you if a variable is not defined or if you try to put the wrong type of data into a variable.  There are plenty of other languages out there that don’t require variable type declarations but I never have spent much time with them.  If you’re used to them it’s probably no big deal but I tend to like the compiler to warn me early and often of any potential issues.  Another little thing about the language is that to assign a value to a variable using the Put command rather than an equal (=) sign.  In LiveCode you would say:

put “ABC” into myStringVariable

In Xojo this same thing would be

dim myStringVariable as String = “ABC”

LiveCode Create DB

Creating an SQLite Database File using LiveCode

Xojo Create Db

Creating an SQLite Database File using Xojo


One of the major drawbacks that I discovered early on was that LiveCode does not make native looking applications.  The good news is that PushButtons look the same on each platform (no mean feat) but it also means that those Pushbuttons don’t look native on any platform.  There are commercial plugins available to make LiveCode applications look native on each platform.  I don’t believe that the plugins are using native controls either so this means that an OS update might ‘break’ the look of an application until those plugins are updated.

LiveCode Mac app

LiveCode App running in Mac OS X

LiveCode Ubuntu App

LiveCode App running in Ubuntu

LiveCode Win8

LiveCode App running Windows 8


Xojo is not perfect in this regard as not all of its controls are native on each platform either.  It does, however, use them whenever possible.  Another drawback to Xojo is that control features are often times the lowest common denominator between Mac, Windows, and Linux for desktop platforms.  This is more for feature parity than any malfeasance on their part.  Xojo web apps and iOS apps use native controls.

LiveCode, like Xojo, lets you create external libraries using C++.  LiveCode calls these Externals while Xojo calls them plugins.  It appears that there is an active community of developers and an active 3rd party development community for LiveCode.

Unlike Xojo, LiveCode comes in two different varieties:  Community Edition and Commercial.  The Community Edition is open sourced and free but limits you to open source and GPL applications.  If you are interested in LiveCode this is where I’d recommend that you start.

There are four different types of commercial LiveCode licenses.  The Indy Commercial license costs $299/year per seat and lets you do closed source and royalty free commercial apps with a $500k revenue limit (how this is enforced I have no idea).  The Business license costs $999/year/seat and eliminates the revenue limit.  The Pro license $1,999/year/seat and gives you more personalized service and a Premium license is $10,000/year for 3 seats and gives you priority support, use of their test suite, extensions, priority features (whatever that means) and a LiveCode conference ticket.

LiveCode also has a membership program that costs $99/year ($25/year for students) and gives you exclusive membership benefits and helps supports the continued development of the platform.  You also get access to over 100 training videos and access to the LiveCode Conference simulcast.

What I Liked About LiveCode

I found the LiveCode Start Center to be clean and uncluttered and useful.  It has four main areas, Projects that shows your recent projects, Getting Started that has handy links to the some beginners videos and guides, Resources that takes you to tutorials, sample stacks, the community forum and their API dictionary, and finally they have a Sample Projects list that has a sample projects in it.

The LiveCode website also does an excellent job of pointing out 3rd party commercial and non-commercial extensions and what they can do for the developer.  They also allow user reviews of the extensions so it makes it easier to make a purchase decision.  I have no idea what it takes to get listed on their website or if LiveCode takes a cut of the revenue but it’s something I wish Xojo would do a better job of helping their 3rd party developers market.

I also found it refreshing that their API documentation allowed user comments.  I really wish Xojo would do something similar because I feel that we, the user community, could add some really useful comments to the documentation.  While I like the Xojo documentation I feel it might be better served by opening it up a bit (with moderation).

LiveCode does deploy for Android which might be a huge bonus for some.  Assuming I could get a UI that looks native it might be the one thing that would make me look at LiveCode with any seriousness if a client asks for Android deployment.

Finally, the fact that part of LiveCode is open sourced is interesting.  They successfully ran a KickStarter campaign to open source the product in 2013 and successfully did a campaign on their own website to fund HTML5 web deployment in 2014.  I don’t know about anyone else but I would help fund certain items for Xojo development even if wasn’t open sourced (perhaps a better grid control?).

What I Disliked About LiveCode

If you’re coming from C++, Java, or any object oriented language I think you’ll find the lack of ‘objects’ to be disheartening.  Add to it that there is no auto complete for the Script Editor and I think it’s a deal killer for me.  Those two features make discovering events, properties, and methods so much easier without having to constantly check the documentation and I think it’s a huge adverting for Xojo.

The lack of strong datatypes, while not a deal killer, scares me a little.  I want to be warned early, often, and loudly when things go wrong and strong datatypes are something that I really find attractive in a programming language.  If there’s a data conversion going on it’s because I want it to happen (don’t get me going on Xojo variants – they’re evil – get over it).  The natural English scripting language also puts me off simply because it’s unnecessarily wordy.  Again, if you’ve never programmed before this might be an advantage.

The lack of native looking controls is also huge drawback for me.  Xojo apps will try their best to look native (though Linux apps require more of a nudge than Mac/Win apps) and while not perfect, out of the box, Xojo apps are generally native.


Is LiveCode worth a look?  Sure.  Like any development environment, if it speaks to you and you can get your projects done in it then it’s the right one for you.  For me, Xojo is a better language, with a better IDE, and has more features that I want.  Xojo is only lacking Android support and I’d probably look more at Xamarin than LiveCode for a variety of reasons.

If LiveCode works for you that’s great.  This review isn’t meant to be overly critical of the tool but as an existing Xojo developer I don’t see enough reasons to switch from Xojo development to LiveCode.  Feel free to leave comments below on anything you feel I missed or got wrong.

Xojo Cloud Database Support

Last week Xojo announced new features for Xojo Cloud.  They now support MySQL and PostgreSQL database servers in addition to SQLite that they have supported since day one.  One of the interesting features with the database support is that db admin tools that support SSL tunnels can connect to the database as if it was running locally.  In my testing it was surprisingly easy to setup and use.

The first thing to do is log into your Xojo Cloud account control panel.  Then simply enable either the MySQL or PostgreSQL database and enable the SSL Tunnel.  In each case you will receive a username and password that you’ll need to copy before moving on to the next step.

Screen Shot 2015-02-26 at 10.28.25 AM

Our MySQL admin tool of choice is NaviCat.  Setting it up was pretty easy to do.  Create a new connection and then navigate to the SSH tab.  Enter your server IP address, the username and password.

Screen Shot 2015-02-26 at 10.32.30 AM

Then navigate to the General tab and enter a Name for this connection (I used Xojo Cloud).  Because you’re using the SSL Tunnel you need to enter ‘localhost’ into the Host field.  Enter your Xojo supplied username and password and then test your connection.

Screen Shot 2015-02-26 at 10.38.00 AM

After that, everything acts just as if the server were local to you.  In this example I created a sample database named ‘bkeeney’ and a table called ’t_temp’.

Screen Shot 2015-02-26 at 10.34.09 AM

Your Xojo web application, then, will connect to it via the localhost parameter along with username and password suppled to you from Xojo.  Because it’s inside the firewall your web app needs to do nothing more.

Setting up a database server in Xojo Cloud really is that simple.  It just works.  From start to finish it only takes a few minutes to get up and running.  It’s a great addition to Xojo Cloud.

Xojo 2015 Release 1

This week saw the release of Xojo 2015 Release 1.  This release has only a couple of new features (and one really big change) but many smaller changes and bug fixes.

The biggest new feature for Xojo is that you can now build 64 bit iOS applications.  This is a big deal because Apple is making 64 bit iOS apps mandatory for those apps submitted to the App Store.  As of February 1st submissions to the App Store must be universal 32 bit / 64 bit app bundles.

In December 2014 Xojo gave us a tentative roadmap and met it as 2015 R1 was in a usable beta on February 1st.  This is an accomplishment in and of itself since Xojo rarely, if ever, gives us their schedule.  Not only gave a schedule but met it!  I’d say lets give them some kudos for being a bit more open and accomplishing their task!

So far in testing it appears that 64 bit iOS applications are solid.  This also means that the 64 bit compiler is working and works in a 32 bit application and debugger.  According to their December 2014 blog post the next up for the 64 bit treatment is Linux web/console and this will be much anticipated by anyone that’s tried to install a Linux web app on a 64 bit Linux OS and struggled to find 32 bit compatibility libraries.

Besides 64 bit for iOS, there are a plethora of bug fixes to the IDE, the new framework, and the compiler.  To say that the IDE received some love would be an understatement.  These changes should make for a more stable development environment.  The number of bug fixes is too many to list here and I highly recommend reading the release notes.

The IDE Icon Editor received another makeover (how many is this in the past 15 years?) that allows it to handle 1024 by 1024 icons.  Some unused sizes were removed and the output format is now PNG rather than JPEG2000.  In my own testing it seemed that images moved forward from older projects didn’t look quite right so you should definitely make sure your icon images are updated before doing a release.

The Web framework received a few important updates.  WebLabels now work properly on dynamically created WebContainers.  WebCheckboxes respond properly on touch devices.  WebContainer mouse event handlers no longer interfere with scrolling.  WebListbox no longer offsets the selection if placed inside a WebContainer and accessed from a touch device.  Internet Explorer now supports gradient fills.

The new framework received new Parse functions for Integer, Double, Single and will act like the existing framework Val and CDbl functions.  What this means, in reality, is that Parse is more lenient and doesn’t throw exceptions when it can’t figure out the value of the passed in Text.  I think it’s obvious that Xojo is mindful of how we are using the new framework and reacting to our (valid) criticisms and wants and needs.

Windows and Linux users didn’t receive much love in this release, however.  The release notes only have a few for each and those seem pretty minor.  One bug fix that affects everyone, but appears to affect Windows more, was the Serial control.  It appears that it was possible to receive incorrect data.

I think many will be happy with this release.  64 bit iOS applications were a necessity and everything else was bug fixes and expansions of functionality.  I wish more releases were like this (i.e. a few new features and mostly bug fixes).

As with any new release you’ll need to test it against your own projects to find out if you have any issues.

What are your comments about Xojo 2015 Release 1?