Xojo vs Xamarin

Last 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.


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.


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.

Xojo Webinar: Xojo Consulting

For some time now Xojo has been doing webinars on various topics.  It’s a great way to learn about Xojo.  In addition to being live (where you can ask questions) they are recorded too.  As time goes on the webinar archives become a really nice resource for new Xojo developers and even experienced developers can learn a few things too.  If you’ve never been to the archive, check it out!

Join me at the next Xojo webinar, Tuesday, July 22,  where I’m guest host!  I will share my 13+ years of Xojo consulting experience.  Learn some of the great things (and not so great things) about being a Xojo consulting.

Come prepared with questions!

Register now at http://xojo.com/support/webinar.php

Xojo and the End of Carbon Support

In a blog post this week Xojo announced that they were dropping support for Carbon applications in Release 3 which is due in roughly 3 months. Furthermore, their reasoning for doing so was because the Carbon framework was causing interference with the ongoing iOS work.

At first blush, the decision kind of stinks. We still have some of our own applications and some client applications still using Carbon. Why are we still using Carbon? Mainly because of inertia. They work just fine as Carbon apps and we’ve identified enough items of concern (mainly threads) that will require some rework. Nothing that we haven’t done in other apps but for various reasons we (or the client) just haven’t bitten the bullet yet.

On the other hand, Carbon was deprecated over a year ago. If you haven’t tried to get your apps working in Cocoa by now I would say you have not been very proactive.

In other words, there was plenty of notice that Carbon was going to die a long slow painful death. Carbon bugs just aren’t going to get fixed unless they were critical and the definition of ‘critical’ gets less and less as time goes on. So it makes sense to just kill it and move on.

What about the iOS part? Well, that’s an interesting twist, I must admit. I can only speculate that getting iOS to work properly with all of the existing platforms was going to cause some major work (and future maintenance) in the Carbon framework. Why do all that work for a deprecated target?

This means that we should all be beating the hell out of our Cocoa applications to make sure bugs are squashed or decent workarounds found. If a Cocoa bug has been keeping you from moving to Cocoa and you haven’t reported it yet it’s your own damned fault. Now you have no excuse.  The clock is ticking.

For us, we have to have the discussion with our clients. Either they move to Cocoa and stay more or less in sync with the latest Xojo or we stick with an older version for Xojo (or Real Studio). The pain can be modest now or major later. From experience the more out of sync you are with the current release the more painful it is to update a project to the current version.

The good news is that Xojo Release 2 should work for many years so if you have to support Carbon apps it’s possible. The bad news is that you never know what Apple’s yearly updates will do to Carbon.  It’s probably just a matter of time before they kill Carbon but whether that’s one year or five only Apple knows.

I don’t see this is a huge deal for Xojo developers. The writing was on the wall for Carbon applications for a while. And honestly, Cocoa isn’t a huge transition for most applications and the end result is a much better application.

What do you think about the end of Carbon support?

Xojo 2014 Release 2

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

Licensing Changes

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

A number of console app memory leaks were fixed.

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

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

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

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


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

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


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

You Have a Contract, Right?

Writing software for others can be a tricky profession.  The client often has totally unrealistic expectations on how software development works.  They give vague requirements (or none!) and expect you, the developer, to read their mind and produce an awesome application.  And therein lies the problem, because there’s a wide difference between their requirements (or lack thereof) and the finished project.  A handshake and a verbal agreement just isn’t good enough – You need to protect yourself (and the client) with a contract and spell everything out.

If you don’t have a contract already, my preferred place to begin is by going to Docracy (www.docracy.com) and looking up contracts.  These forms aren’t perfect, but they’ve been looked at by lawyers, and in-lieu of hiring your own lawyer, a heck of a lot cheaper.

The basic contract has little over a dozen sections.  I’ll just highlight a few of the sections that seem to grab peoples attention.

A payments section is obvious.  It gets into the details of how you’re getting paid.  More detail is good.  What’s the rate?  How long is it good for?  Is it a fixed bid?  What is the payment structure?  Do you have a separate rate for bug fixes and for how long?  When can you revisit rates?  Do you take check or credit card?  Do you have a fee for taking credit cards?

The expenses section should detail everything that you are paying for out of your own pocket (like computers, development software, etc.) and what you expect the client to reimburse you for.  This could include travel expenses, special services, software, or plugins required for the project, postage and courier services or any number of legitimate things.  The point is that you need to document it!

One section that has caused me some issues over the years was the intellectual property ownership section.  Every client wants to own the code you’ve written and this section gives any patents or trade secrets developed for the project to the client.  I have, as many consultants do, a stable of controls and classes that I reuse on nearly every project which really can’t be the clients’ property when the project is done.  This is where the consultant’s materials section comes into play.

Consultant’s materials are the tools, or pieces of code, that were in existence before the work began that you use to get the job done.  You can give the client nonexclusive rights to the software with some exceptions (spelled out of course), or you can attempt to retain the rights to your own software.  Regardless, this section should be read carefully so that you and the client thoroughly understand the implications.  It has been my experience that this section almost always needs an edit or two to satisfy everyone.

A lot of clients also require a confidentiality agreement section that says that you won’t talk about your work for the client to others without permission from the client.  Sometimes they also want a non-compete section stating that you won’t work on similar software for a certain number of years.  Make sure that you understand the implications of these sections because it might mean you lock yourself out of an industry!

All of the above is fairly generic and is applicable to nearly all contracts.  In my format, the exhibit document is where a bulk of the details occur.  Here is where I list my deliverables, the client deliverables (I don’t like doing graphics so I usually require that the client do them), a listing of any requirements that I’ve received so far (referencing emails and other documents if need be), assumptions that went into the bid, payment schedule and amounts and milestone dates.  As you can image, the exhibit may be much larger than the rest of the contract.

In the client deliverables section, I always state that the client is responsible for final application testing and that they are responsible for end-user support.  The reason that clause is in there is that a client assumed I was doing all the testing and was going to perform end-user support.  This is why writing everything down is so important!

One of the assumptions I generally add into my Xojo projects is that Xojo can actually do what I, and the client, assume it can do.  I only had one issue ever come up and because of that assumption we were able to negotiate a slightly higher contract price to purchase a pricey third-party control.

In the exhibit I add a section that describes how long after the final sign-off I’ll fix bugs for free.  I also state the rate for the following year on program changes (new functionality, not bugs) and when I can renegotiate pricing.  This section can be contentious.  I’ll fix true bugs for a long time, but a lot of times the client doesn’t understand what a bug really is and how it’s different from their poor (or nonexistent) requirements.  If you find a problem client, this will probably be one of the areas that causes you grief.

There’s a lot of information that will be in your contract.  It’s designed to protect you and your client against poor assumptions.  It provides a way for you to handle the client and set their expectations upfront.  In the long run, a good contract will be the roadmap of your projects.

Why have a contract?  Because not having one may cost you  a lot of money.  I turned down a project a few years ago because the prospective client balked at having to pay money up front.  In indignation he claimed in 30 years he’d never paid anyone up front.

He then proceeded to go through the rounds of contractors and they all turned him down for much the same reason.  Finally, he found a developer that was looking for some extra money but already had a full time job.  He did the work (without a contract and without any up front payment).  And, as you can imagine, the client shafted him in the end.  Said that it didn’t work as promised so therefore wasn’t going to pay.  The client was full of it because he walked away with the source and never looked back.

The developer lost thousands of dollars and had no way to enforce it since he didn’t have a contract in place.  Even having a contract won’t stop a client from not paying but at least with a contract the developer could have gone to small claims court to recover some of the money.  No contract meant no such recourse was available.

I think we all have contract horror stories.  Have any that you’d like to share?

Be Paranoid About Your Data

Last week wasn’t a very good week.  Over the weekend the hard drive on my iMac failed and by failing Mac OS X said it couldn’t repair the drive so it came up read only mode.  So I did the sensible thing and copied the entire contents to my external Drobo (essentially striped RAID).

Then Monday morning the Drobo wouldn’t boot up.  It would just do a continuous boot and restart.  Not good, but at the end of the day all of our most important stuff, the source code for projects, is stored on a commercial source code hosting service.  In case of theft or disaster of my equipment I’m only down as long as it takes me to buy a new computer and download the repositories.

The Mac hard drive was replaced by Monday night and by Monday afternoon Drobo tech support had the Drobo back up and running.  They didn’t give a reason but I suspect that because the Mac had hard crashed a few times (due to the bad drive) it got into a state that it didn’t know how to recover from.  But it works and I didn’t lose any data.

Tuesday when things started to go back to normal we couldn’t reach our source code hosting service, Code Spaces.  On Twitter they said they were experiencing a DDOS attack and I didn’t worry to much about it.  They’re the experts, right?

By Wednesday they still weren’t back up.  A little concerned I went to their website and found the message that you never want to hear.  They accounts had been hacked and ALL of their repositories had been deleted.  Oh, and pretty much immediately they are ceasing operations as a company.  You can read more about it at http://www.codespaces.com and http://www.electronista.com/articles/14/06/18/hosting.company.returning.what.data.it.has.left.financially.crippled.by.attack/

So much for the offsite backups.  The fact that the backups could be accessed through their Amazon Web Services account should give anyone pause for concern.  Is your web services company really paranoid enough to protect your data?

I know more than a few people have given Xojo some grief that their security for Xojo Cloud is over the top.  Maybe it is, but then you hear stories like this and you start to wonder if maybe being overly paranoid is a good thing.

So here is my advice.  Have multiple sources of backups.  Keep one source in a safety deposit box and update it regularly.  Use a commercial host that you trust.  There’s no guarantee they they won’t be the next Code Spaces and get hacked but hopefully this incident was a warning to them to be more paranoid and strengthen their security procedures.

I know of developers that backup everything to a thumb drive on their keyring.  I’m not sure that’s entirely secure but if that makes them feel better so be it.  At least their source code is always with them.

While last week was not a good week at least I’m learning to be even more paranoid about my data.  Being paranoid about your data is a good thing.

Debugging Your Xojo Applications

Your customers and clients expect your Xojo applications to be as bug free as possible.  What mechanisms do you have in place to handle an error and report it?  Bugs occur – that’s a fact of life – and even the best error handling in the world can’t prevent bugs from occurring.

Thoroughly testing your application is your first and best line of defense.  However, it’s very time consuming and without good testing procedures it may even be a waste of time.  I would also add the it’s very hard for the developer to be a good tester of their own code.  You programmed it to do a certain task in a certain way.  Someone else will have a different set of expectations.

Regression testing is the only way to really make sure that changes in one part of your code doesn’t change other parts of your application (or a new version of Xojo doesn’t affect you either!).  An excellent way to do regression testing on your software is to use the open source unit testing module called XojoUnit (it’s now part of Xojo).  It allows you to test your code with known inputs and test them against the actual output.

A common question from the forums is that people get an error message saying, “The application has encountered an error and must now shutdown,” and they have no idea what the error is or where the error happened.  They need to learn as much as they can about the Exception class and in particular the Stack property.  The stack was introduced way back in 2006 and is a string array that contains the methods that have run from the entry point into your code until where the exception occurred.  Be aware that the Include Function Names property has to be true in your application for the stack to be human readable.

Use the UnhandledException event in the application class to capture any errors that weren’t handled elsewhere.  The exception stack allows you to determine where the error occurred and from there it’s a simple matter to send an email, post to a web form or write the error out to a log file that includes important details such as platform, operating system version and the version of your application.

Some applications will require files be in a specific location and when debugging your application those files might not be in the proper (final) location.  Use the DebugBuild constant along with conditional compilation, #If,  to handle things differently at debug time and runtime.  For debugging purposes you can have the required files in the local project directory for convenience sake.  A feature added in 2007 allows you to place your debug build in a particular location which eliminates the need to have non-project files in your project directory.

Cross-platform applications require additional handling but now that Xojo with (or without) a desktop license can do remote debugging and it’s very easy to do.  I run the Xojo IDE on Mac OS X on an iMac and use VMWare running various versions of Windows and Linux so I can debug my applications in those environments.  The remote debugger works exactly like the regular debugger except that the debug application is running in another environment.  It’s a little slower to initiate since the app has to be transferred to the other environment but otherwise it’s the same process.

I highly recommend testing early and often on the other platforms you’re developing for.  Don’t wait until the end to do extensive testing.  While Xojo does a great job on cross-platform applications there ARE platform differences you need to be aware of.

New developers coming from Visual Basic 6 are often irritated by the perceived lack of database error in Xojo.  An incorrect SQL statement when opening a recordset results in nil recordset objects instead of a throwing a runtime error.  The unexpected nil recordset then causes NilObjectException errors.  You must get in the habit of checking your database object for errors after every database operation.  Once you catch the error you can at least be more graceful on how to recover from it.

That’s a lot of information so do your research.  Debugging your application isn’t as hard as you think.

What things do you do to make your life easier hunting down or preventing bugs?

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!


New Web App Training Series

BKeeney Software is proud to announce a new 4 1/2 hour video training series for subscribers at http://xojo.bkeeney.com/XojoTraining/.  The new LinkShare Web App series takes budding Xojo developers from nothing, to a fully functional web application.  This eight part series is designed to familiarize the beginning and intermediate developer on how Xojo web applications are created and how to create the basic infrastructure required for most modern web applications.

Just a few of the topics covered:
• Project organization
• Database integration using ActiveRecord and ARGen
• Safe password handling, storage and login procedures
• Sending emails and how to communicate with the app via URL parameters
• Basic WebStyles
• Basic WebPage, WebDialog and UI layout and interaction
• Much, much more

The series comes with source code the Xojo developer can use in their own projects.

BKeeney Software has 183 separate videos, with over 52 hours of Xojo and Real Studio training video and source code at http://xojo.bkeeney.com/XojoTraining/.  The site is a Xojo web app and has served up over 7,750 hours of streaming video to thousands of developers since it went live.

More information at http://xojo.bkeeney.com/XojoTraining/ or contact Bob Keeney at support at bkeeney dot com.

ARGen Version 1.6

ARGen256Today we released an update to ARGen, our utility to create ActiveRecord classes for your Xojo and Real Studio database projects. ARGen costs a mere $19.95 and can save you many hours of tedious and error-prone database coding.

ActiveRecord for Xojo does a number of things for you. First, it eliminates much (not all) of the SQL required to work with your database. Second, it lets the IDE autocomplete work for you using Table.Field notation as well as letting the compiler warn you when you are doing an illegal datatype conversion. Lastly, ActiveRecord will throw an exception if a field is missing from the AR classes (debug only).

Version 1.6 is a free update to all users of ARGen. The demo version allows you to output two AR classes at a time.

New in version 1.6:

  • ARGen now outputs the entire ActiveRecord class structure so you no longer have to download the ActiveRecord package from our website to add it to your project.
  • Outputs only for the database you’ve selected
  • Restructured the OpenDB a bit to include the table registration

Download and more info at http://www.bkeeney.com/allproducts/argen/