Quite often prospective clients, and developers thinking of learning Xojo, ask my opinion of Xojo. They are about to embark on a journey spending tens of thousands of dollars on a cross-platform tool and they want to know if Xojo is a right for them. It’s a good question and I’ll share some of what I share with them in no particular order.
Xojo is pronounced “Zo Jo”. I can’t tell you how many times I’ve heard it pronounced “Ex Oh Jay Oh” or something else. They just don’t know and I think it spooks a lot of people as it doesn’t exactly roll off the tongue. Xojo has been around under various names (REALbasic and Real Studio) for twenty years – all with the same company. At that point it’s easy to name a dozen languages/development environments that were popular twenty years ago that either don’t exist today or been sold so many times that they’re now obscure tools.
This isn’t your fathers BASIC. Xojo uses the BASIC syntax but this isn’t like the venerable Visual Basic or even older GWBasic or QBasic. Xojo apps are NOT interpreted at runtime – they compile down into native code for each of the platforms. The language itself is a modern object-oriented language that happens to use the BASIC syntax. Xojo is updated three to four times a year and has undergone a lot of upgrades in the past two decades. It first supported 68000 code, then PowerPC and Fat applications, Carbon, and now finally Cocoa on the Mac side. They’ve added Windows, Linux, Raspberry Pi (Linux ARM), desktop and console application targets. In the mobile space they’ve added iOS, and by the end of the year Android. They’re also in the middle of the transition from 32-bit only applications to 64-bit applications. For the most part things ‘just work’ and developers don’t experience too many issues (bugs happen but think about how many targets they’re supporting!).
Xojo applications are self-contained. Take a compiled Xojo application and (with very few exceptions) literally copy the files to another computer and the application will just work. Even Windows applications don’t need an official installer, however, it is recommended since most Windows users are comfortable and familiar with using them. Most Mac applications are installed via drag-and-drop from a disk image but an installer can be used on the Mac as well. This ease-of-installation is huge and it’s rare to have “DLL Hell” issue since all required libraries and resources are bundled together. This does make the resulting output larger than some other development tools that depend on system libraries but I’ve rarely seen this an issue.
Xojo provides nearly everything you need in one tool (with some caveats). The Xojo IDE has Code, Form, Menubar, Database, and Report editors (to name some of the big ones) in one tool so you never have to use another tool. We’ve found the database editor to not be powerful enough so we prefer external database editors. The built-in reporting tool also isn’t very powerful so we created our own reporting tool (Shorts) which has served us well in our consulting projects. The nice thing is that all of the built-in tools work seamlessly with each other so the tools that are powerful enough for you ‘just work’ with few hassles. The editors try really hard to protect your from hurting yourself while other tools are just a big text file that must be in an exact format.
The Xojo community is incredibly helpful. The Xojo Forums are filled with some of the most helpful people I’ve ever met. Some of the Xojo engineers respond to questions, but usually the community answers before they get to it. Many other support forums are rude and condescending to newcomers to their language/tool. The Xojo forum has even been known to answer questions about other tools.
Xojo is a cross-platform tool and because of this it has some compromises. Controls are often the lowest- common denominator. Grids especially aren’t as powerful as some are used to in the Windows world. This is mainly because complex grids are not common in Linux and Mac environments. Other controls have similar issues. Things like automatic spell checking in TextArea’s are platform specific as on the Mac. At times it is disappointing that there aren’t more control options for Xojo right out of the box (think date and calendar controls) but thankfully there is a third-party market for controls and libraries for Xojo that can often help. Even though much is provided for you, it’s possible for a developer to use OS API’s using Declares that can significantly modify the appearance and functionality for some applications.
Xojo is a Rapid Application Development (RAD) environment. Between the all-in-one IDE and the language creating applications in Xojo is fast. This means that an initial investment can get your app developed faster and cheaper than many other languages. Obviously some of this depends on the developers doing the work but it can make a huge difference. We’ve always told clients that if they’re not happy with Xojo performance after the initial release they can use our code as the proof of concept to the developer in whatever language they choose. There have only been a handful of clients that have ever switched languages after release and that’s usually been switching from desktop apps to web app.
The cost of Xojo isn’t very high compared to some tools. For $699 per year per developer you can create web, console, and desktop apps for Mac, Windows, Linux, and Linux ARM plus iOS apps. That’s all in the same environment and same language and with the exception of iOS applications (which requires a Mac) you can use Mac, Windows, or Linux to create everything. Many developers use third party controls and libraries and even those are relatively inexpensive. Plus, there are no royalty fees for your Xojo made applications. All-in-All it can be a relatively inexpensive tool.
What considerations have I missed?
Have I told you how much I love the Xojo community? I’ve been part of it for fifteen years and I’ve met hundreds of Xojo developers at developers conferences and probably exchanged emails with thousands more. I am amazed at how much this community helps each other and I wish there was a way to promote that as a key feature of the product. It’s a big deal. Really!
If you’re just starting out using Xojo know that there are a bunch of people, myself included, that are willing to help out, if we can, on your journey. Programming is hard. Well, I don’t think it’s hard because I’ve been doing it for so long, but it is complex at times and that makes it hard. Just ask your question in the Xojo forums and you’ll almost always get an answer within hours.
Even Xojo pros, such as myself, have need of help. Xojo covers Mac, Windows, Linux desktop, console, and web apps. It does iOS apps for iPhone and iPad. It now does Raspberry Pi for heavens sake! It works with dozens of different databases. There is simply no way any one person is going to know everything there is to know about Xojo. It just can’t happen. So yes, I go to the forums, all the time, and ask for help.
Just the other day I asked for some help with WooCommerce. Not Xojo related, really, but certainly related to a project we’re working on for a client. Within a few hours I had half a dozen developers private message me saying they might be able to help. Subsequent contact narrowed that list down a bit but the point is that I have probably shaved off several days worth of work simply by asking for advice.
I am biased towards Xojo, naturally, as it’s been my primary development language for fifteen years. I think I’d be hard pressed to find such a friendly community. I call many on the forums my friends even though I’ve never physically met them. The few that I’ve met in person have lived up to their forum reputations and are really friends for life.
So maybe this is my belated Thanksgiving post. I am thankful that so many years ago I jumped both feet first into the tool. I asked questions – many of the silly and redundant. I became more proficient and then made another jump to start blogging about it, making products for other developers, and training the next generation of developers.
So if you are in need of a cross-platform development tool I highly recommend Xojo. It ain’t perfect but no development tool is. If you jump in I think you’ll love the community. I know I do.
What say you fellow Xojo developers?
If you’ve spent any amount of time making cross-platform applications in Xojo you probably hate icons as much as I do. I’m no graphic artist and because of this I’ve paid good money for several icon sets. These icon set are fine but they’re pretty basic/generic and don’t tend to look right in macOS, Windows 8 and above, or even iOS. And that’s just for application icons. Making icons for documents, disks, folders, and the like, are just as big a pain to make. Each platform has several different styles and getting it right is awful.
Ohanaware introduced Iconographer last week. This is the tool I’ve been waiting for! Iconographer lets you easily make icons that are consistent for their target platforms all while keeping the overall identity intact. Not having to use a high-end graphic tool, like PhotoShop is worth it to a developer geek like me.
Using it is easy. Simply drag your starting image into the editor window and start manipulating it. At the top left of the window there is an expanding toolbar, for lack of a better word, that lets you pick the Icon Type: Application, Folder, Disk, Document, and Web Icon. Below that you have options for the target. Depending upon the Icon Type you have the option to pick the Target. For Application you have macOS, Windows, and iOS but for the Folder Target you only have macOS and Windows.
To the right of the drawing canvas you can pick the style of the icon. For macOS you have Blank, Circular, Rounded Rectangle, Tilted, Rounded Square, and Plugin. For Windows you have Blank, Windows Tile, and Use Different Application Icon. Similar styles are there for iOS.
Below the Styles is the Layers list that lists the layers in the selected Style. I will be honest, I had issues figuring out how to manipulate the layers. You can add layers using the ‘+ Layer’ button where you can add Shapes, Images, and Text.
Adding Text also was problematic for me. Once I added a Text object I couldn’t always select it until I had rotated it and then reset it to zero. Then, if I had two text objects I never was able to edit and change the text of the first one. I chalk this up to possibly not understanding what the shared label is. At times I also had a weird purple selection rectangle that I was never able to get rid of.
At the bottom of the drawing canvas is, perhaps, one of the more useful features of Iconographer. The Eye lets you select from a number of environments to preview your icon in an About Window, the macOS dock, and even the Mac App Store, to name a few. This is a great way to preview your app in an actual environment and lets you make decisions while in the application instead of having to leave and use a graphics application.
Once you’re done you can build your icons. It takes the currently selected Icon Type and all of the selected Targets and outputs them into the directory of your choice. For macOS it will create an icns file and for Windows an ico file. It really is that easy. It would be nice to have the ability to export SVG format too. If you’re creating a suite of icons, say for application, document, and disk, you have to do it in several steps but that I suspect that most developers won’t have an issue with that.
Iconographer is a must have for any cross-platform developer. It’s ability to make consistent application and document icons for macOS, Windows, web, and iOS easily and quickly make this an invaluable tool.
Iconographer works on macOS X 10.10 and better. It normally costs $19.99 but Ohanaware has an introductory price of $9.99. More information can be found at http://ohanaware.com/iconographer/.
It’s been an interesting couple of weeks in the cross-platform development world. First, Microsoft announced that they were purchasing Xamarin. Xamarin and Microsoft have always been friendly and this move isn’t very surprising. As a Mac user much of the marketing verbiage doesn’t talk about the Macintosh, just iOS along with Android and Windows Phone and Windows apps. Xamarin has always seemed to be mobile first and desktop last, so again, this doesn’t seem surprising.
Many people really like Xamarin and there are a number of Xojo developers that have tried it out. Their opinion of Xamarin isn’t very good: limited support, expensive, buggy IDE, and slow building of apps are just a few of the major complaints. In comparison Xojo, they say, is ‘fast and lean’.
This week Microsoft announced that SQL Server, their Windows-only database server will be ported to Linux and be available in 2017. This seems to be a tacit agreement that their biggest weakness in the server world is Linux. Linux is extremely popular and since it’s cheaper to deploy than Windows they have to do something to stop the hemorrhaging. Perhaps they’ll sell a boatload of licenses but it’s tough competing against the free or inexpensive database servers like PostgreSQL. Again, no where are they talking Macintosh OS X.
This news makes me happy that cross-platform app development is getting some attention. When the big boys of the world are pumping money into it then there must be something to it.
It also makes me sad since I don’t see Xojo changing their focus. For many years they have had this hobbyist/part-time developer first mentality. This has hurt them with professionals looking for a new development tool. There are many things, I believe, that hurt them in this market. I’ll list a few here:
- It’s a BASIC language: No getting around it. It’s a modern object oriented language that compiles down to native code, and (mostly) uses native controls doesn’t seem to matter much. VB6 screwed up many peoples opinions of language for better or worse. In reality, there are lots of really good VB6 apps out there but many more poor VB6 programmers.
- The IDE: especially the Code Editor. It doesn’t let you do bad things and that’s great for beginners. Usually it’s the first thing people complain about, though. It’s limiting, and forces you into the Xojo way of doing things. No other major IDE, that I’m aware of, forces this restriction upon their users.
- Lack of basic controls: I’ve been using Xojo for 15 years and have a tool chest of controls and libraries that I use on a daily basis. But still, the lack of even basic Date/Calendar controls is a turn off for many first-time users. Add in very poor RTF support, no PDF support, and especially no true grid control and you have a lot of strikes against the tool. Yes, you can turn to the 3rd party community for some of these (and they are not very expensive) but to not have any of these things hampers adoption.
- Reporting: I don’t know of any serious Xojo developer using the built-in reporting tool. It’s just not robust enough for most peoples needs. We’ve used several 3rd party tools over the years and in the long run wrote our own (BKS Shorts).
- Android: iOS was a big addition to Xojo but without Android it’s not convenient to do a lot of mobile development with Xojo. To add Android is a huge project and unlike anything they’ve done to date. I would expect a minimum of eighteen months but probably more like two years of major development work to get it into Xojo even as a beta. And that’s assuming they announce it.
I use Xojo all day every day and use it for dozens of commercial desktop applications and dozens of Xojo driven web apps. Xojo is mostly stable and under constant development. Just in the past year they’ve added iOS and Raspberry Pi development as well as added 64 bit compiling for Mac OS X, Windows, and Linux. Much of the limitations you can overcome by dipping your toes into the 3rd party market – but that market is tiny in comparison to many other development tools.
So my wish is that Xojo would focus more on business needs. Identify the features that business owners need and implement them. Include more basic controls and charge more for advanced controls that not every developer will need. Get reporting cleaned up. Make database programming smarter and less error prone.
It is my firm belief that if you get the business users you’ll capture the part-time and hobbyist programmers along the way. Many of the hobbyist and part-timers only care about one platform and that’s only a $99/year investment. If you want to do cross-platform desktop that’s only that’s $299/year. For every desktop license you need three single licenses.
A Pro user like myself needs desktop, web, and console apps for sure. iOS is a nice add-on but not necessary for us at this point. The Pro license costs $699/year. You need seven single licenses to make up for it. My company has four licenses and we renew every year. So my business is the equivalent of twenty-eight single license users and while I might grumble at writing a check every year for license updates it’s nothing at what we used to pay for VB6 and 3rd party licenses every year. At one point it was $2,000 per developer per year. That’s just the price of doing business.
So tell me, which type of customer should Xojo focus on? What do you think their biggest weakness is in capturing some of this nascent cross-platform market?
We released version 1.5.4 of the Report Designer today. One of the bigger changes is it ships with a web example of how to take a report definition and display it for a web app. This affects a significant amount of methods and properties throughout the project to make them work on desktop and web but seems to work well.
BKeeney Shorts (with report designer) is 100% Xojo code (DynaPDF Starter kit required to export to PDF) and comes with a drop in Report Designer and Report Viewer component for both desktop and web apps.
For purchasing information please visit http://www.bkeeney.com/allproducts/bkeeney-shorts/
Version 1.5.4 change list:
- Major code changes to allow most classes to work in web apps too.
- Simply copy BKS_Shorts_ReportDesigner folder into your existing web project.
- Delete PAF_PrintKit.DesignCanvas (desktop ScrollCanvas subclass)
- Create a new PAF_PrintKit.DesignCanvas that is a WebCanvas subclass
- Changing text values in the Properties List is now Case Sensitive
- Added Portugese Localization
- Added a commented out example of how to connect to MySQL without using the winDBConnection Window.
- See winRPTViewer.Display
- Fixed an issue that would cause the SQL statement to not be saved properly in the JSON string
- Added a Default Style if none is in the local dictionary
- How reports are saved so they can be viewed without first having to be in the designer
- WARNING! YOU WILL NEED TO RESAVE ALL OF YOUR REPORTS
- Cleaned up some localizations and made some more strings dynamic.
- Made the Report Designer the default pushbutton in Demo Window
- New Report opens a new Report Designer Window instead of copying the current connection. (this affected menu handlers in odd ways one wouldn’t expect)
- Created a Web Example
For years we’ve been using eSellerate for purchasing and licensing and registration of our apps. We’ve recommended it to clients too and, for the most part, it’s worked quietly, steadily, and hassle-free for many years. Their plugin is still using the old Real Studio format and they’ve said in several emails that they will not support Xojo going forward. With Xojo moving to 64 bit in the R3 release it’s time for us to look at alternatives.
We liked eSellerate for a number of reasons. For one, it was pretty simple. Once you learned the intricacies of their web portal it was easy to add products. Their sample app sucked but we figured out a better sample and offered it as an example for others on our website. After years of using them I could set a new product up in as little as five minutes. Then, they handled all of the various sales taxes and VAT for the states and countries that need it.
After the purchase, eSellerate would send an email to the user with purchase details. This included license code, download instructions, and any other messages that we wanted to give them. And all of this without any intervention on our part. It just worked.
eSellerate also has an in-application purchase which we found to be pretty useful. Users could purchase the application without ever having to leave the application. For some people this was a nice feature but I’m not sure how necessary this is any more. Lot’s of people purchase things over the internet with no qualms.
When it came to the registration part of things they had a number of nice features. I could control how many machines could be activated with a single license. This led to some instances where users didn’t deactivate a license on an old machine and couldn’t activate it on a new one. However, a 30 second trip to the eSellerate web portal usually solved this.
On very rare occasions we’d get a user that couldn’t activate an app because of security restrictions on their network. To solve this eSellerate had a manual activation process that would bypass all of that. It was kind of tedious but then that’s why it’s called a ‘manual’ activation.
Bundling products together was pretty simple and even setting up payments to a third party was easy. It was flexible and I know it was used in a number of bundle offerings over the years because of its simplicity.
So now we are on the hunt for the next purchasing/licensing/registration system. We could write our own but I really don’t want to do that for a lot of reasons I won’t go into here. Ideally, we’d find an existing system that integrates into our website that takes a variety of payment types and also handles sales taxes. The last thing I want is to get hounded by a government entity – I just want that to happen automatically.
I’d also like to keep the per machine registration with restrictions on how many activations a single license can do. It must work on Mac OS X, Windows, and the most popular Linux distributions. Not that we have a lot of Linux applications but we have some and I don’t want two different systems if I can help it.
The in-application purchase and registration was nice but that’s not necessary any more. I think most people are comfortable now buying over the internet. However, offline activation is still something that is a requirement. There’s no telling where customers are and what security restrictions are in place.
I guess the other part of the equation is that I, nor or customers, need something them an arm and a leg. I’ve see a few licensing schemes that want $300 per product per month. While they seem really nice, that’s above and beyond what we want and need.
A few names that have come up recently are LimeLM, Paddle, FastSpring, and I suppose even the venerable Kagi is in play. FastSpring is more of an eCommerce front end so what are you using for application licensing?
What I’d like, Dear Readers, is for you to share your experiences, both positive and negative for any of the services listed. Have any missed any that should be on the list?
The Spell Checker plugin has two different spell checking modes. In the first mode it works with the native spelling dictionaries on each platform. On all versions of Mac OS X (that Xojo supports) and Windows 8 and above it uses the built-in spell checker dictionaries. If you can’t, or don’t want to, use the native dictionaries you can use the Hunspell dictionaries. There are hundreds of Hunspell dictionaries available for use in a variety of languages and speciality industries.
There is no Linux version at this point due to lack of interest.
More information, including downloadable demo, pricing, and usage is available at http://www.bkeeney.com/allproducts/bks-spell-checker-plugin-for-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.
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”
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.
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 is really powerful because it gives you multiple ways to create really powerful controls. Today I’ll discuss subclassing, extends, and containers.
First, subclassing a control is really easy to do. Create a new class and set the super to the control you are extending. A great example of this is the Xojo ListBox. In its raw form it’s powerful, but limited, in its functionality. To have those awesome alternating row colors we subclass the ListBox and put our code in the CellBackgroundPaint event.
One of the things that people forget to do when subclassing the control is to repeat the events that that they are using. Because I’ve used the CellBackgroundPaint event it’s not available to any instances of the class. Sometimes this is desirable, but sometimes you want the control to still have those events.
The solution is simple. Define a new event named CellBackgroundPaint and use the same properties and return value. This means that you, the developer, can have the alternating colors in your listbox but also still have the opportunity to override those colors if you need them.
The other powerful thing about subclassing is that you can continue to subclass them all you want. In one of our projects we have the following Listbox hierarchy: ListBox -> AlternatingRowListbox -> CustomCellListbox -> RecordsetListbox. Each one is still a Listbox, but each gets all of the events and properties of its supers so this means that the RecordsetListbox automatically gets the alternating rows even though it specializes in loading the listbox by using a Recordset.
Sometimes, though, you only want to add a single method to a class. Creating a subclass to do this might be overkill, especially if you have to go back and and retrofit this change in a lot of places. A good example of this the PopupMenu where you often have to set the text of the PopupMenu to some value. The code is often like this:
if pm.list(i) = sSomeValue then
pm.ListIndex = i
It’s not hard but after you’ve done this several dozen times you come to the realization that this should be automated somehow because it’s a lot copying and pasting and if you find a better way in the future you’ll hate yourself (trust me, I’ve done this). You could easily subclass the PopupMenu and go through and change the Super of all existing popupmenu’s, but there is an even simpler way of doing this: Extends
Extends lets you create your own method that acts like it’s part of the class. If we were to take our code above for the PopupMenu and put it into a module (it won’t work in class objects like Windows) our code would look like this:
for i as integer = 0 to pm.ListCount-1
if pm.list(i) = s then
pm.ListIndex = i
Same code, just using the extends. What’s great about this is that using it super easy. It becomes part of the AutoComplete list and is a ‘dot’ extension (just as if it was a subclassed item). So calling it is like this:
I don’t remember when the Extends method was introduced but since it was introduced the number of Subclassed items in our projects has dropped dramatically. Using Extends fails in one area and that’s Properties. If you need a property for the additional functionality, you’ll still need to subclass the control and add the property to the subclass.
This final method may confuse some people. Using a container control isn’t a subclass nor using the extends. Containers are incredibly powerful controls in Xojo, though, because they allow you to create combinations of controls (and their subclasses) in unique and reusable ways. A great example of this is a typical Save/Cancel pair of pushbuttons on a dialog or window. On Macintosh OS X the Save button is on the right and the Cancel on the left. On Windows it’s opposite. In Linux, it’s the same order as Windows but the buttons have a different height.
There’s nothing stopping you from adding code to every window that has this Save/Cancel combination so that they’re in the proper location and height. But why? This is Xojo, a modern object oriented language! Plus, I hope you’re as lazy of a programmer as I am because that’s a lot of work. Use a container!
Create the container, add the pushbuttons. I named my buttons Left and Right because their function is determined at runtime depending on the platform. I add an Open event and in that event I add code like this:
btnRight.caption = kSave
btnRight.Default = true
btnRight.cancel = false
btnLeft.caption = kCancel
btnRight.Default = false
btnLeft.Cancel = true
btnRight.caption = kCancel
btnRight.Default = false
btnRight.cancel = true
btnLeft.caption = kSave
btnRight.Default = true
btnLeft.Cancel = false
The kCancel and kSave are dynamic constants holding the proper strings. In the ActionEvent of the buttons I have code like this to raise an event to tell the parent container (a window or another container) what happened:
#if TargetMacOS then
RaiseEvent Action false
RaiseEvent Action True
#if TargetMacOS then
RaiseEvent Action true
RaiseEvent Action False
And finally the Action event which I’ve defined is:
It’s really as simple as that! No matter which platform I’m on the Action event from this container tells me if the user pressed save or cancel.
Why did I include Containers in this article? Good question! It’s because you can think of Container Controls as a way to subclass Windows or WebPages without it being a window/page. You can reuse Containers as many places as you want and when you change the original it changes the children (be aware though that there are some caveats with this statement – especially with WebContainers). And even better is that you can dynamically add and remove containers at runtime. Adding them is simple by using the EmbedWithin commands and to remove them use the Close method (I always set their visibility to false first).
We use a LOT of containers in our consulting work. We find that it tends to simplify the code (remember being a lazy programmer isn’t a bad thing). We’ve had windows/pages that have thousands of control and hundreds of controls visible at any given time but with a UI that complex we like to break them out into Containers. So rather than having a Navigator with a listing of thousands of controls (and their labels!) we break it out logically into containers and the Navigator has maybe a dozen containers instead.
Each container has Save, Load, Validate set of methods (sometimes this is using an Interface) and whatever other methods are required but the point is that the overall window/page doesn’t need to know, or care, what the individual controls are and how to load, save, and validate their data – it only has to know enough to call the Load, Save and validate methods in each container.
With Xojo for Web, containers are even more important because you can create ‘repeating rows of controls’ that are very complex. We wrote an entire accounting application for a client in using Xojo for Web and as you can imagine creating an Invoice Line Item row that needs Qty, Price, Amount, Sales tax and the necessary UI to add and delete the row, void a row, make it non-taxable can be complex. Sure, we could have come up with a UI that doesn’t have that in a list, but frankly, it’s not that hard using WebContainers.
Containers are very powerful things and a great way to combine controls into one unit. It’s also a way to create a dynamic control that can easily be added a runtime. Rather than using a ControlSet (i.e. control array) and cloning an existing control (and having to keep track of the index) you can dynamically place your container that holds your one control. We don’t use this technique very often but it does come up every now and then.
Subclassing a control in Xojo is pretty easy but sometimes overkill. Using the extends method works great if you’re adding methods to a class/control and don’t need to add any properties. Containers are powerful constructs that let you combine controls into a reusable object that have their own events and that can be added dynamically. As a Xojo programmer you should be familiar with all three methods.
Did I forget anything?