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.

Conclusions

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?

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.

Changes

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.

Conclusion

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.