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.

Subclassing vs Extends vs Containers

Xojo is really powerful because it gives you multiple ways to create really powerful controls.  Today I’ll discuss subclassing, extends, and containers.

Subclassing

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.

Extends

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:

for i as integer = 0 to pm.ListCount-1
   
   if pm.list(i) = sSomeValue then
      
      pm.ListIndex = i
      
      exit
      
   end
   
next

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:

Sub SetText(extends pm as PopupMenu, assigns s as String)
   
   for i as integer = 0 to pm.ListCount-1
      
      if pm.list(i) = s then
         
         pm.ListIndex = i
         
         exit
         
      end
      
   next
   
End Sub

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:

pmFont.setText = sTheFont

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.

Containers

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:

#if TargetMacOS then
   
   btnRight.caption = kSave
   
   btnRight.Default = true
   
   btnRight.cancel = false
   
    
   
   btnLeft.caption = kCancel
   
   btnRight.Default = false
   
   btnLeft.Cancel = true
   
#else
   
   btnRight.caption = kCancel
   
   btnRight.Default = false
   
   btnRight.cancel = true
   
    
   
   btnLeft.caption = kSave
   
   btnRight.Default = true
   
   btnLeft.Cancel = false
   
#Endif

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:

Sub Action()
   
   //btnLeft
   
   #if TargetMacOS then
      
      //Cancel
      
      RaiseEvent Action false
      
   #else
      
      //Save
      
      RaiseEvent Action True
      
   #Endif
   
End Sub

Sub Action()
   
   //btnRight
   
   #if TargetMacOS then
      
      //Save
      
      RaiseEvent Action true
      
   #else
      
      //Cancel
      
      RaiseEvent Action False
      
   #Endif
   
End Sub

And finally the Action event which I’ve defined is:

Event Action(bSave as boolean)

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.

Conclusions

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?

New Video: TCPSockets

Today, I added a new video to our Xojo training area. This new video guides you through the steps to using TCPSockets in your Xojo applications. In this nearly 90 minute video we create a sender application and a receiver application and by sending some simple data (a command and data) to the receiver to make sure we’re processing everything properly.

Then, we send a file (of any size) from the Mac sender app to the Windows receiver app. We do some basic file metrics to make sure the file we receive is the same as we sent. In the video I forget to unpack part of the data properly and it’s this file checking step that finds the problem (sometimes doing something wrong is instructive in these videos)!

Screen Shot 2014-10-08 at 10.16.38 AM

After that, sending a folder full of files is no big deal and in the video we clearly see that the sender has a queue of files that it’s going to send in multiple data segments, and the receiver only has a few of the segments yet.

Finally, we create an acknowledge message that gets sent back to the Sender application proving that we can have two way communication between the applications.

http://www.bkeeney.com/XojoTraining/xojotraining.cgi?video=339

We now have over 55 hours of training video of Real Studio and Xojo.  Since we rewrote the training area using Xojo for Web we’ve served up over 8,700 hours of streaming video to thousands of developers around the world.

Xojo vs Xamarin

AndroidLast week when I was the guest speaker on Xojo’s webinar on consulting, I fielded a question regarding Xamarin.  The basic gist of the question was if I felt that Xamarin was a threat to Xojo.  At the time I had heard of Xamarin and read a few articles on it but that was about it.  In the week since I’ve been doing more research on the topic.

Xamarin is an interesting development tool.  To sum up what it is in a sentence or two probably does it some injustice but here’s my take.  Xamarin takes the C# language and .NET framework and has ported it to Mac OS X, iOS, and Android.  This allows developers to use the Visual Studio IDE on Windows, and Xamarin Studio users on Mac OS X and Linux to create native Mac OS X, iOS, Android apps, in addition to Windows desktop and Windows Phone apps.

I threw Mac OS X in there since it’s listed on their website but it appears to more of an afterthought since the focus seems to be on mobile applications.  Indeed, their mantra is that they want to make the best development experience for mobile applications.

I am not a C# developer but like most modern languages it’s not the language that’s difficult to learn it’s the framework and .NET is arguably one of the biggest and most advanced frameworks around.  Having the .NET framework available for iOS, Android, and Mac OS X is a huge advantage for anyone already familiar with it.  Theoretically it should make the transition from Windows developer to cross-platform developer very easy.

Xamarin uses native platform user interfaces and compiles to native applications for each supported platform.  This is good in that you get the best of each platform.  The not so good is that it appears that you’ll end up coding each user interface separately (see Xamarin.Forms later on).  I can see the arguments going both ways on this whether this is good or bad.

Unlike Xojo, Xamarin does not have a built-in forms editor.  They give the option of building Cocoa and Cocoa-touch applications strictly via code or by using Apples Interface Builder.  You either stay in Xamarin to build everything via code or you exit to Interface Builder to design your UI.  I can’t imagine that’s very efficient but Interface Builder wasn’t always integrated in Xcode either.  As a developer you have to roll with the punches.

The Xamarin framework has some cross-platform calls to make life easier, but when it comes to iOS and Mac OS coding it appears that most of it is similar to Xojo’s ability to make declares into the native OS.  Again, you might call this a strength as you get the Apple methods but it also means that you’ll need to know each target OS in detail which can be a rather large learning curve.

Xojo abstracts as much of the platform as possible which means that a TextField on Mac OS has mostly the same capabilities as a TextField in Windows and Linux.  The strength in Xojo means that you don’t need to know the details of each platform but it also means that you generally get a compromise in functionality.  This is where system declares can really aid the Xojo developer.

Web Presentation

Xamarin’s website is gorgeous.  Nearly everywhere you go there are very helpful tutorials and videos explaining how to do things.  It’s also laid out in such a way that you can quickly find things.  The Xojo website is okay and relatively easy to find things but Xamarin goes out of their way to convince you to use their development tool.

The tagline on the Xamarin home page is “Create native iOS, Android, Mac and Windows apps in C#.  Join our community of 687,765 developers.”  Practically everything about the website screams, “Use me and you’ll make a great applications!”  It’s very professional looking and it’s all business.

The tagline on the Xojo website reads, “Create powerful multi-platform desktop, web & web-mobile apps.  Fast development.  Easy deployment.”  It’s not that Xojo doesn’t attract professional developers but their emphasis is on different things.

One thing that surprised me quite a bit was under the Support/Consulting Partners menu of the Xamarin website.  It’s a listing of Xamarin consultants and they are listed by tier (authorized or premier), by geographical region, and by expertise.  The Xojo website has the Find a Developer page.  The first says that it’s a serious language with a lot of software development partners and the other says that it’s a smaller community.

IDE Comparison

The Xamarin IDE is fairly simple and seems to be a hybrid between Xojo and Xcode.  Their Solutions pane is not nearly as complex as the Navigator and is far simpler and easier to use, in my opinion.  The Solutions list only shows objects unlike the Xojo Navigator that shows everything (methods, properties, constants, enums, etc) as you drill down into the object.  As you select an object in the Solutions list the source code editor loads all your source code.

If I had a major beef with Xojo is that they try too hard to dumb down the IDE.  You can’t just start typing away like you can in practically every other language/development environment I’ve ever seen.  Instead, you are forced to add methods through the Xojo UI.  You’re forced to do the same thing with properties, events, constants, enums and so on.  While this is great for people just starting out in Xojo it’s a limiting factor for more experienced users and forces you to use the mouse – a lot.  This means you can only see one method at a time unless you open up multiple windows whereas the Xamarin source code editor shows you everything in the source code.  Method definitions are defined via text in the code editor and not by a specific user interface.

Xamarin has the prerequisite autocomplete in the source code editor and appears to be work roughly the same as Xojo’s.  One thing that I REALLY liked about Xamarin was a tool tip showing you what the current parameter was.  As the user types the code editor recognizes where it is and provides a tool tip with a hint on what it’s currently expecting for the parameter.  This was one of my favorite features from VB6 and sadly, Xojo’s source code tip is an antique by comparison.

Xojo has a built-in forms editor.  Not only that but it has a reports editor, menu editor, database editor, as well as specific editors for a bunch of one-off items.  Xamarin shows objects and source code – that’s it.  So this forces you to either build all the UI via code or via an external editor.  While the Xojo editors aren’t perfect they are there and easy to use.

If you purchase the Xamarin Indie subscription (or better) you can use the Xamarin.Forms module which allows you to build iOS, Android, and Windows Phone screens from a single code base and it should speed up development.  However, I think Xamarin faces similar hurdles to Xojo in that a bug in their framework requires a new release so it’s no panacea.  And, you still build the UI via code not through a GUI editor.

Pricing

Xamarin comes with four different subscription options.  The Starter Subscription is free and is good for individual developers and allows you to deploy Android, Windows Phone, and iOS apps to a device and to their respective app stores.  Apps are limited in size and you are forced to use the native UI builders.

The Indie Subscription costs $299 per year, per developer, per platform.  If you were interested in iOS, Android, as well as Mac OS X this would cost $807.30.  Apps are unlimited in size and can use Xamarin.Forms.

The Business subscription costs $999 per year, per platform, and per developer.  This gives you Visual Studio support, “business features”, and email support.  The same Android, iOS, and Mac bundle jumps to $2,697.30.

The Enterprise subscription costs $1899 per year, per platform, and per developer.  This adds Prime Components (pre-built UI assemblies), guaranteed response time of a day, hot fixes, an individual manager, a bunch of support and code troubleshooting options.

Xojo pricing is much simpler by comparison.  $99 for an individual platform license with a $99 1 year renewal.  $299 for all desktop apps (Mac, Windows, Linux) with a $150 1 year renewal.  $399 for web apps (running on Mac, Windows, or Linux computers) with a $200 1 year renewal.  $999 gets the Pro license which gives you all desktop, web, database server, and console/service apps, consulting leads, and beta program access and the 1 year renewal is $500.  The Enterprise license at $1,999 is everything as Pro with an additional day of custom training and the 1 year renewal is $1,999.  All of the licenses are for a single developer.

Xojo is considerably less expensive but the Xamarin pricing is inline with what professional developer organizations are used to paying for their tools.

Conclusions

If I were a C# developer I would be all over this product – especially if I wanted to my apps running on non-Microsoft computers and devices.  I believe this is where many of the nearly three quarters of a million developers are coming from.  I’m sure there are plenty of other developers that were tired of developing their mobile apps on one or possibly even three separate development tools too.  Xamarin makes the development process easier  by using a single tool.

Xamarin is really pushing mobile app development.  Based on the forum activity I suspect that Mac OS X isn’t in the limelight but because iOS is so similar I can see why it was added.  It’s another notch in the capabilities checklist for a growing tool and user base.  If you can do all of your development with one tool why wouldn’t you?

Xojo really isn’t competing in the same space as it’s for only desktop and web applications (an iOS version is currently in alpha testing and should be released this year).  Xojo has been doing cross platform desktop and console applications for nearly two decades and has transitioned through 68k, PPC, and Carbon to Cocoa on the Apple side as well as all the Windows and Linux variants and versions.  Web apps are relatively new but the framework is very much the same as the desktop side.

From what little we’ve seen of the iOS version (remember that it’s in alpha testing right now) it has a built-in forms editor and uses pretty much the same framework as the desktop and web (with specific differences, of course).  It promises to make developing for iOS extremely easy.  However, Xojo has no current plans to support Android or Windows phone.  This might be the one key difference that might make Xarmarin an attractive development environment for many.

Will this consulting company be switching from Xojo to Xamarin anytime soon?  No.  The cost of migrating to a new tool, retraining, and getting involved with consulting in a new environment is considerable.  If Xojo went away tomorrow I know which tool I’d look at first.

Classic Visual Basic Is Truly Dead

Developers love Visual Basic.  The site http://www.classicvb.org/petition/ has received well over 14,000 signatures since its inception in 2005.  In the user forums for Microsoft Visual Studio there is a place where developers can make suggestions.  This one http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3440221-bring-back-classic-visual-basic-an-improved-versi wants to bring back class Visual Basic.  Since December 2012 it had received over 7,400 votes.  Microsoft essentially told VB6 developers to kiss off this week.

The only bit of good news, in my opinion, for VB6 developers was that the VB6 runtime will continue to be supported through 2024.  So, VB6 users, you’ve got 10 years to figure out what’s next.

The VB6 runtime it is still a component of the Windows operating system and is a component shipped in Windows 8.1. It will be supported at least through 2024.

The 1100 (and growing) comments to this post are pretty much what you’d expect.  There are a lot of frustrated VB6 developers that feel Microsoft has abandoned them, at best, and, at worst, actively screwing over one of the most vibrant developer communities on the planet.

Many VB6 developers feel that .NET is inferior to VB6 but yet Microsoft is confident that VB6 developers will somehow migrate to .NET.  I just don’t see this happening.  Oh, I’m sure some will bite the bullet and learn .NET but the prospect of learning a new language and rewriting their apps does not make many happy.  VB6 was effectively killed 10 years ago and yet there are still lots of VB6 developers out there.

Many will be looking at alternatives because Microsoft is not the 95% market share behemoth it once was and VB6 was, after all, Windows only.  I you have to go to the trouble to learn a new language and rewrite all of your apps why not look at something that can work on Windows and Mac and possibly Linux as well?

I spent many years working in VB6.  I liked the language, I liked the IDE.  It had some awful quirks that drove us nuts but they were well documented quirks and were relatively easy to work around.  When I first encountered Xojo (then REALbasic) I felt like I found VB’s kissing cousin.  The IDE’s were similar, the language was similar and it was relatively easy to convert code and community was outstanding.

After twelve years of using Xojo I can say it’s superior in some ways.  First, it’s kept up to date and gets roughly 4 updates a year.  This is both a good and bad thing.  Good because when Apple (and to a lesser extant Microsoft and the Linux Distro’s) change things you’ll know that it’s just a matter of a few months, usually, before a new version of Xojo is released.  Unfortunately this makes Xojo a moving target which is part of the reason why there aren’t any books on Xojo.  It gets written and by the time it’s published it’s already out of date.

There are a number of things that VB6 was just not good at.  Subclassing controls was impossible and we never got threads to work right without causing serious crashing issues (I believe I recently saw a post where they got threading working properly in VB6).  But that still leaves all the other things that were feeling their age in VB6.

I’m biased for Xojo.  I think it’s worth taking a look at if you’re a VB6 developer.  Is Xojo perfect?  Hell no.  The developer community is much smaller and there aren’t nearly as many control options.  And some of the controls, the grid in particular, are inferior to what many are currently using in VB6.

Xojo is, in many respects, a compromise.  All of those fancy grids you see in Windows apps usually don’t exist on Mac OS X and Linux.  Mac OS X apps are generally built with a different UI mindset so the the grids aren’t nearly as busy.  If you planned on doing the same thing in Xojo you will be in for a rude awakening.  Not that you can’t make a complicated grid, but you’ll spend a lot of time getting it to work and even then I’m not sure you’ll be happy with the results.  Plus, Mac users are a finicky lot and if it looks like a Windows port they might reject your app.  But then again, does the utility you wrote for your company really need a fancy UI?

Xojo is very cool sometimes.  The ability to remote debug applications from my Mac to a Windows or Linux computer is very handy.  And the fact that a Windows machine can build for Mac OS X and Linux, for console, desktop and web apps, is also very nifty.

Take a look at Xojo (it’s free to try!).  It might be a good solution for you.  My advice is to not try to ‘convert’ your VB6 app using The Migration Assistant or any of the conversion tools available.  There are just too many language and control differences to make this feasible.  From experience, you’ll spend more time fixing code than if you had just started from scratch.

My other bit of advice is to not assume Xojo and Xojo made apps work just like VB6.  They don’t.  Take the time to read the documentation, look at the example apps, and visit the forums when you have questions (you’ll have many).  The Xojo community is very welcoming and eager to help.

Finally, I am a consultant and if you need assistance getting into Xojo we can help.  My team has rewritten dozens of commercial VB6 apps over the years.  If you’d like a quote feel free to download our VB6 analyzer tool at http://www.bkeeney.com/vb2rbconversion/.  We also have over 50 hours of Xojo and Real Studio video tutorials available to subscribers at http://xojo.bkeeney.com/XojoTraining/ where we’ve helped thousands of developers get a handle on Xojo.

If you are a VB6 developer, Xojo might be for you.  Welcome to the Xojo community!

 

Container Control Love

We are big fans of Container Controls for a lot of reasons.  Containers, in my opinion, are one of the most powerful tools in Xojo and they are often misunderstood and under used, in my opinion.

Complex UI

Complex UI

In the first picture you see a very complex layout.  The client only wanted a single window for everything.  Each item in the family list is its own container.  Each of those containers has a tab control and you can see a fairly typical layout.  In almost every case each of the tabs has its own container as well.  The project takes it to the extreme but adding these dynamically is really fast.

Screen Shot 2014-02-15 at 2.06.15 PMThis project was a conversion from VB6 and everything really was in one window.  It was a nightmare to debug and in the process of converting it and breaking it apart into containers we found numerous errors they had never been able to find due to the shear amount of code in this one window.  To load the container we simply create a new instance of one (if it doesn’t already exist), give it the database file and the container literally does everything else.  The Xojo window has about 200 lines of code for everything.  The old VB6 window had over 10,000 lines of code.

Containers let you create really complex UI layouts and treat it as a single entity.  I see this a lot with projects with tab controls where each tab has 30 controls on it and you have 10 tabs.  That’s a LOT of controls and logic to load and save the data to them.  What we do is create a container for each tab and the container has the load, validate and save logic.  Then we place the container on the tab control or page panel.

Doing things like this does a couple of things for us.  First, it makes the coding of the Window very simple.  Instead of having 300 controls you have 10.  When the Window is opened or when the user presses the tab to expose it to the user we tell it to load the data (this is where using ActiveRecord comes handy).  The window itself doesn’t know or care about the individual controls.  So all the code for the container is where it makes the most sense – in the container.

The second thing this does is simplify what the IDE has to display.  I’ve made no bones about it that I do not like the Xojo Navigator.  The more objects you have in it the worse it gets.  Finding stuff is hard and I find it to be a royal pain.  Using containers reduces this issue.

The only real drawback to using containers at this point is that they draw really slow in the Layout Editor.  This appears to be addressed in the latest 2014 R1 beta but until it’s actually shipped you never know if it will get pulled for some as yet undiscovered show stopper bug.

Containers are also the only reasonable way to make repeating rows of controls.  Many people bag on Xojo for not having a powerful grid component but I think by using Containers you can do a lot of the same things.  To make a very sharp repeating rows control you need to have at least 4 different containers.  The overall container, an inner bounds container, the overall list of rows, and finally the row itself.  This is for desktop apps only since you can do the same thing in Web with only two containers.

Doing this type of repeating row control is not possible in carbon apps since the controls do not respect the container bounds but it works in Cocoa apps.  In Windows there is no issues but in Linux you need to use the new transparent property on all of the containers so the controls will respect the bounds of the container.  Xojo just did a blog post on this.

The drawback to the repeating row strategy is that you don’t want to have hundreds or thousands of rows.  Each container consumes memory and they can quickly make your UI slow and unresponsive.  At that point it’s much better to page your data so that your user can only see x number of rows at a time.  We usually settle on 50 as a nice starting point.

As I said earlier, Web Edition repeating row lists are even easier.  You simply add the container row to the container list and it knows to add a scrollbar.  It also knows how to scroll when the user uses the mouse scroll wheel.

One caveat about this is WebDialogs.  There is a super nasty bug in the framework where WebDialogs don’t get events like they should.  If your web dialog, and subsequent container, happens to be over a WebListbox and you try to scroll, the underlying listbox will receive the scroll events.  If you find this happening to you, you can try disabling the listbox.  Still, this bug sucks.

There is huge overhead using the EmbedWithin method in web apps.  Every time you use it the app has to serve up a new page and send it down the pipe.  I saw an example project the other day that had 50 rows and each row had 10 container cells on it.  With very little data and no style information it took almost have a second to display the repeating list in the browser on the same machine.  Add some additional time going over a slower connection and your app looks slow and unresponsive.

The answer for now, is to not do that.  The performance of the embed within command is simply too big to use it a lot.  We had one largish web project where we used containers for each of our tabs and were adding them at runtime.  It was not good.  The lag time was simply too big so we ended up embedding the containers into the page at design time.  Now we take a little bit of a hit when the page is first displayed but the user doesn’t notice anything when they switch tabs.

If you are not using containers you really might want to look at them again.  They really are powerful tools.  With a little time and practice you can make your coding life easier while developing some incredibly complex layouts.

Xojo Calendar Classes 1.0.3

WeekViewWe released a minor update to our Calendar Classes today.  In version 1.0.3 we fixed a bug that prevented multiple day events from drawing properly.  We also added a new event so users could use their own localization on the Hour formats.

The BKS Calendar Classes is canvas subclass allowing you to have Month, Multi-Week, Week, and Daily Views (24 hour view) calendars for your Xojo and Real Studio applications.  We have two versions, the Standard license is an encrypted set of classes and for those needing to get to the full source code we offer the Professional license.

More information at http://www.bkeeney.com/calendar-classes-for-real-studio/

Xojo Licensing Changes

Xojo, Inc. confirmed last week that the licensing for Xojo is changing.  The IDE now costs nothing.  Free.  Zip.  Zilch.  Nada.  Now we all know that it’s awful hard to stay in business by not charging any money, so the catch is that to make a build you need a license.  If you’re building for desktops (Mac, Windows, Linux) you need a desktop license.  Building for Web you’ll need the web license.  Building a console app you’ll need a console license.  The only oddity in the mix is if you’re using database servers which requires an additional license SQLite is included in all licenses).

Now that the IDE is free all users can take advantage of all Xojo features.  Item encryption, server sockets, SSL support, database encryption, remote debugging, container controls, code profiling, IDE scripting and build automation are the big items that were not available to all users depending on what license they had for Real Studio.  This has some advantages for training and getting people to actually use those features.  Everyone has the same set of features and all are available on all supported platforms.

Announced Pricing is this:

Console Licenses $100 ($50 renewal)

Desktop $300 ($150 renewal)

DB Servers $300 ($150 renewal)

Web $400 ($200 renewal)

So what does this mean for those with existing Real Studio licenses?  Real Studio personal licenses automatically get a Xojo Desktop license.  Real Studio Professional get Desktop, Database, and Console licenses for Xojo.  Real Studio Web licenses get converted to Xojo Web and Database.

Real Studio Enterprise licenses now get what’s called Xojo Pro.  Xojo Pro gives you all licenses.  You get desktop, console, web, and database licenses.  It comes with Priority Support which means that Xojo Inc. will handle all Priority Support issues first and then everything else.  Pro licenses also work on three machines (in contrast to the two for other licenses).

Another feature for Xojo Pro is that it gives you guaranteed access to the beta’s.  The Real Studio beta list really had no restrictions.  You signed up and you got access.  They didn’t say this but I suspect this is in response to the many people on the beta list that never reported anything but generated a ton of useless chatter.  This will definitely cut down on that problem.

Some people have taken offense to this.  They are not going to be Xojo Pro users so they feel that they’ll be cut out of the beta list.  The wording in the keynote was very specific.  Xojo Pro gives you ‘guaranteed’ access to the beta list.  That does not mean that you can’t join the beta it just means that it’s up to their discretion.  Those that have contributed in the past will most likely be welcome.  Those that have not are probably out of luck.

Another advantage of getting a Xojo Pro license is access to a Xojo Pro Only forum.  They figure it will most likely be the full-time developers (such as BKeeney Software) that use it.  Honestly, I have a problem with this even though I will most likely have several Pro licenses.  I have been a top 10 poster in the Real Studio forums for many years and I just don’t see how this helps me, or the community.  It seems like it will introduce some stratification into the community where there is none now.  I can’t imagine having an issue that I wouldn’t ask the entire community about.  I could go on about this but it seems to me that it’s a marketing bullet-point to make Pro look better.  I think it’s a bad idea and probably won’t use it.

The final ‘advantage’ of the Pro license is that Feedback cases now get a 3x multiplier. Real Studio licenses are a little different.  I believe Personal licenses get no multiplier, Pro/Web gets 3x and I thought that Enterprise licenses now get a 5x multiplier.  So in this scenario everyone else gets no multiplier but Pro users are the only ones to get it.

The Feedback multiplier isn’t a huge change but it definitely favors the Pro license.  I like this but I have my doubts that it will change anything significant.  As a pro user I have needs that are not being met by Real Studio (and now Xojo) despite many years of blogging and generating feedback reports.  Instead they have consistently gone for marketing bullet-point solutions and solutions that make it easier to sell to beginner and hobbyist developers.

Don’t get me wrong.  The free licensing has the potential to introduce Xojo to a lot of people that would consider themselves hobbyist or part-time developers.  That’s a good thing.  But it’s the folks like me (the Pro’s) that spend serious cash.  I want and need features that a) make my development life easier or b) help make me money (usually in completing things faster).  Not a whole lot of those types of features have been introduced in the past five years.

What do you think about the new licensing and the Xojo Pro features?

Protect Your Most Valuable Asset

If you own a house, most likely you have insurance in the event of a disaster.  You might even have a safe box somewhere in your house to protect your valuable objects and you might even have a safety deposit box at the local bank to protect your most valuable items.  Why do many developers not use a Source Code and Version Control System for their source code? After all, your source code is the most important business asset you have and until you hand it over to the client it’s yours to protect. Even if it’s your personal code, why not protect it?

Real Studio doesn’t make this easy, in my opinion, with their binary (rbp) file format. The binary format is very fast and very portable single file in comparison to the version control (vcp) file format that creates a text file for each object in your project. The binary format, in my opinion, gives users a false sense of security. Bugs happen and hard drives fail.

Version control systems can not read the binary format and track code changes. They check in a binary file as a whole unit regardless of how many Real Studio objects are in it. So it doesn’t matter if the code in Window1 has been changed or not because all that code gets sucked into the server.

In my ideal world I’d love to have a format that works with the source code systems but is also as easy to package up and move around as the binary format. Apple’s bundle format would be ideal but as far as I know there is nothing built-in to Microsoft or Linux distro’s that does this automagically.

Subversion servers (and their like) tracks source code changes down to the line of code. Change the capitalization on an RB keyword in Window1.open event? It’s a change that’s noted in the object file (window1) and even to the line of code. When you check in the changes to the server it knows who did it and assigns a version to it.

We’ve used a variety of systems over the years. Many years ago we used Visual Source Safe, CVS, and we currently use Subversion. There are a lot of developers that are using GitHub with a lot of success. Regardless of what you use I believe you should be using some form of source code and version control system. It’s the smart thing to do as it’s the only safe way to store your source code.

Have you every lost code because you failed to keep a copy of it, deleted it accidentally, your hard drive failed, or your computer was stolen? There’s nothing worse than knowing you had some source code that you can no longer find and use. That’s an asset that you’ve now lost – forever.

I know I’m not the only developer that’s worked on a piece of code for a few hours only to realize that it’s crap and I have to revert to the pristine version (because it’s impossible to undo all the changes you’ve just made). You can do this with the binary format if you are really, really good (or paranoid) about making copies of your project but that’s a lot of work. The source code and version control systems are designed for this!

These systems let me save incremental changes, create snapshot copies of the entire project and even compare files across versions so that I can see exactly what’s changed. With multiple developers on a project this is nice to see who changed what and when. When the developer commits a change we all add a note on what we were working on. This is important for us on large projects.

These systems just aren’t for teams, though. Tracking your individual changes is important because sometimes you’ll just be wrong when you change some code and you’ll have to check out an earlier version. These features are very important on projects and teams of any type of size.

Subversion and GitHub can be done on a local computer (not necessarily a server) and from what I know they are not exceptionally hard to install and setup. We chose a commercial host for a variety of reasons. First, I don’t want to purchase and maintain a server with all of the security nightmares that can come with it – the commercial host keeps up with security issues and we all connect via SSL so we know our code is as safe as our passwords allow.

While we do backups of our important files the commercial host is an offsite backup for us.  They do offsite backups of their servers. I know that if my office were to burn down, get hit by a tornado or flood, I would be down as long as it would for me to get a new computer from the nearest Apple retailer and hook up to our Subversion server. That’s a huge peace of mind for me.

We use a Subversion client that is cross-platform simply to make it easier for training purposes. We use SmartSVN which has versions on Mac OS X, Windows, and Linux. While we spend 99% of our time developing our Real Studio applications on the Mac we occasionally need to compile or debug natively in Windows or Linux. The standard UI across platforms with SmartSVN makes this easy and we do not have to copy files across development environments.

We also use a bug tracking system. Unfortunately our version control and bug tracking aren’t tied together but there are plenty of commercial hosts that have both. We tend to commit based on bug reports or, at a minimum, clusters of bug reports. Have a single bug in a class? That’s one commit with the bug ID noted in the commit report. Have a couple in a set of related classes? That’s one commit with all the bug ID’s noted in the commit. At a glance I can tell what bugs were fixed with each commit.

So regardless of the reasons that appeal to you the most, you should be using some form of source and version control system. Protecting your source code assets should be a part of your practice. If you aren’t protecting your most valuable assets your playing with fire. A disaster on your development computer could put you out of business. Protect your source code and yourself.

What about you?  What do you do to protect your source code?

Has Microsoft Already Lost?

I say this with no malice when I say that Real Studio is a fairly small player (development tools-wise) when compared to Microsoft and Apple.  Those two behemoths have much bigger pockets and drive the development environments on their respective platforms.  It’s also fair to say that each has little interest in supporting the other platform.

Real Studio is a good cross-platform development environment that lets a skilled developer create nice Macintosh OS X and Windows applications using one code base.  Most things ‘just work’ and the language makes it easy to take into account the occasional (and sometimes not occasional) platform specific API calls and differences.  Sometimes the differences are a royal pain but rarely have we been stymied in a project as there always seems to be another option available.  And sometimes the trick is know which things to avoid when working on cross-platform apps.

When I started doing Real Studio consulting a decade ago most of the clients who found us were hard-core Apple users.  They had to satisfy their corporate bosses by developing mainly for Windows and if they could get a Mac OS X version as a side benefit that was great.  For the past couple of years it seemed that the clients who contacted us were the corporate IT folks that had legacy Visual Basic projects and didn’t want to convert to .NET (and yes, the boss wanted a Mac version too).

In the past year, however, we’ve been contacted – a lot – by clients invested in .NET and needing a Mac version.  This isn’t just for their internal business apps either – they’re talking about commercial applications.  What’s even more interesting is the number of calls we’ve fielded by existing .NET development shops needing help.

So it begs the question:  Has Microsoft lost the battle of mindshare?  Has Apple now wedged their way into consumer and corporate America to the point where not having a Mac version of your software is a detriment to marketing and sales?

Don’t get me wrong.  Microsoft isn’t going away any time soon, but I can remember a time when if you mentioned Apple (or any non-Microsoft technology for that matter) you were derided for your obvious stupidity.  I can’t tell you how many times I was laughed at for being an Apple developer.  Now, it’s hard(er) to find diehard 100% Microsoft-only IT person.

I decided to write this post after yet another phone call with a .NET developer.  They want Mac versions and they’ve already decided on Real Studio.  But, and this is always the catch, they’re good at .NET and know next to nothing about Real Studio and nothing about Mac development.

That’s where consultants like us come in as we can help bridge the gap in knowledge.  If you’re interested, we have 36 hours of training video’s (over 100 individual videos) available to subscribers at http://www.bkeeney.com/RealStudioTraining/realstudiotraining.cgi including several projects that start from scratch.  I’ve had experience Real Studio developers tell me they’ve learned a few things even by watching the 6 hours of non-subscription video.  Perhaps your .NET developers would get something out of the training?  Perhaps some one-on-one training would helpful?  Contact me – we can help.

I digress (sorry for the shameless plugs).  Have you Real Studio developers been seeing similar trends?  Does .NET seem to be losing its luster?