Should you Mix and Match Old and New Framework?

When Xojo introduced the iOS framework when Xojo 2015 R1 came out we got introduced to the new Xojo framework.  It was only required for iOS and were told that it would eventually get added to the other targets.  Xojo 2015 R2 introduced much of the new Xojo framework into the desktop framework.  Many people are curious if it’s time to start using the new framework.  Is it safe to use?

Let’s get this clear up front.  There is no reason why you have to use the new Xojo framework.  Sure, it’s the future but the old framework will work for many years to come and there are huge gaps in the Xojo framework that haven’t been addressed yet.

My first bit of advice is to not dive headfirst into mixing and matching the old and new frameworks just yet.  It can be an exercise is frustration.  Take, for example, this bit of code:

dim d as new xojo.Core.Dictionary

d.value(kMachineName) = MachineName.ToText

if d.value(kMachineName) = “” then

Looks like it should work on desktop, right?  It doesn’t because when you get to the comparison it generates an exception.  When you break it down it makes sense because the Auto value you get from DictionaryValue is a Text type and you’re comparing it to a String type.  The two are not equivalent.

The way around this, that seems to work, is to do this:

dim tBlank as Text

if d.value(kMachineName) = tBlank then
   break //handle error

Obviously if I was using Text everywhere this wouldn’t be a problem.  But this is a desktop app and the major gaps in the Xojo framework start to show up.  The database classes will only accept Strings so you have to do some conversion.  This isn’t a big deal, but it’s one more thing to worry about and deal with when exceptions come up.

99% of our consulting applications are database driven so not having the database classes in the new framework are a major hindrance to us to adopting the Xojo framework.  Frankly, if it weren’t for the client wanting us to use the new framework whenever we can we’d not be using it yet.

Some of the parts of the Xojo framework that are done aren’t fully fleshed out.  For the past couple of weeks I’ve been working with the class.  Works great on Mac OS X and Linux (surprisingly enough) but when I get into Windows for testing it just does nothing – no exceptions, no errors – it just absorbs commands.  The first reports of issues happening in Windows were reported in back in August but that report was closed as not reproducible.

When it comes to the networking classes the new TCPSocket class still hasn’t been ported to non-iOS targets yet.  Neither has any of the UDP and ITC classes and, in general, there are still a lot of old global framework classes that haven’t been ported yet.

This makes sense because iOS and then 64 bit took a lot of time and resources to get to the state they’re in today.  I would argue iOS isn’t complete yet but that’s an argument for another day.  It looks like 2015 R4 will be mostly Retina support so we are many months away from some of these gaps getting filled.

I am curious to hear other Xojo developers experience with using the new framework.  For me it’s been frustrating from the lack of examples in the documentation, to it just working differently than the old framework, to the new classes not working as they should, to not having a complete framework to pull from and the messiness from commingling the old and new frameworks.  My advice would be hold off on trying to use the new framework in a desktop, console, or web app until there’s more of it.

What’s your experience with the new framework?

Xojo Conference in London

With a little over a week to go there’s still space available at the MBS Conference in London the 27th of November.  It will be held at the Antoinette Hotel in Wimbledon which is a part of greater London.  The conference homepage is at  There are still spots available!

This is during the Thanksgiving Holiday weekend for the United States but if you want to avoid your crazy relatives join us in London and get your geek on.  Airfare is reasonable this time of year to London.

Give it some thought and think about joining us.  I went to one of the conferences in Koblenz, Germany a few years ago and had a blast.  There is nothing like getting together with like minded people to chat about your favorite development tool.

I’m going to give a presentation on BKS Shorts and the new Report Designer that will soon ship.  I think people will be very happy with the ability to embed a report designer into their applications AND have the ability to modify the UI as they see fit.

Xojo 64-Bit Apps and Raspberry Pi

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

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

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

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

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

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

If you want to dive into Xojo and Raspberry Pi I highly recommend you take a look at the Xojo GPIO page on the Einhugur blog at

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

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

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

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

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

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

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

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

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

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

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

Using UI to Store and Manipulate Data Is Not a Good Idea

I’ve fielded a number of questions from developers over the years asking about the Xojo Listbox.  They question is if it’s a good idea to store and manipulate data in the Listbox.  While it’s possible, I say the answer is no, the Listbox is NOT a good place to store and manipulate data.  It’s also a poor place to put your business logic.

The Listbox is a user interface element.  It’s job, if you will, is to present data to the user in a grid.  Along the way you get the added advantage of resizable columns, sortable columns, the ability to do things in the cell with text, checkboxes, and even doing your own custom drawing and handling.  It conveniently allows us to stash data in row, column, and even cell tags and therein lies the delicious dilemma for users that need to manipulate data.

It’s common to see Xojo developers load a listbox and while it’s loaded manipulate all data in its cells and cell tags.  Their listbox events are filled with code to do things to other cells, and tags, and there is often a lot of code for business logic in them.  Then, when it’s all done, they save it off in whatever format they’re using.  This is all fine but it’s a royal pain to debug because most people don’t think about using a constant value, say kAverageValue, but instead say me.cell(iRow, 5) = str(NewAverage). To be honest this works well until you add a new column.  Then, all of your code for the cells to the right of the new column is wrong and you won’t know it until you test.

Another thing that I’ve seen happen is conversion errors.  The developer stashes a numeric value in the listbox cell and formats it.  Then has to go through the process of converting it back to a number for use in the database or file.  This often leads to issues that, again, can be tricky to track down.

Instead, we recommend using a data class that represents each row of data.  The whole list of data can be thought of as an array of data and we store each row in the row tag property.  What it boils down to is that when you’re start working with the data you manipulate the data in the data class rather than in the UI.  Then you update the UI from the data class.  The heart of it is your data class and it’s there you should put your business logic.  If cell 5 can’t be a negative number if cell 1 is greater then 100 it might make more sense to put the validation code in the data class rather than in the listbox itself.  That way you can do validation logic based on class property names rather than listbox row and column values.

If iAverage > 100 and iSetPoint < 0 then

is easier to understand than

if me.cell(row, 1).val > 100 and me.cell(row, 5).val < 0 then

The other thing that’s bad about depending upon the UI to store your data is now you are tied to that control.  I know developers that have invested a lot of time using the StyleGrid and when it wasn’t updated they spent a lot of time rewriting it for the listbox.  Some rewriting is inevitable, but if you can uncouple your data and your UI it’s much easier to move to another control later on.

We use ActiveRecord a lot and whenever possible we put our business logic in it rather than the listbox.  Does this mean that we get rid of all logic in the listbox?  No!  If column 0 can’t be negative, ever, then by all means put that logic in there.  But if the value in column 0 depends on another column we try to put it in the ActiveRecord data class.  The listbox simply becomes the input and display mechanism for the class.

Am I suggesting your go rewrite your listbox today?  Absolutely not, but perhaps the next time you want to make your listbox jump through hoops, perhaps you uncouple the data and put your business logic in a data class rather than in the listbox.  You might like the results.

Thoughts?  Do you agree or disagree?

VB6 and Windows 10

It looks like the Visual Basic 6 holdouts can breathe yet another sigh of relief.  Visual Basic 6 seems to work with Windows 10 as do VB6 apps, though not without some caveats.

I’ve been reading a few threads in various forums where most people have had few to no problems developing VB6 apps or running them in Windows 10.  I’ve seen at least one VB6 developer that claims they’re OCX laden application has issues when loading.  They say that some of the controls simply fail to load at runtime.  Funny enough, it happens only on 32 bit Windows and 64 bit Windows 10 works fine.  They gave no information if these were new installs or legacy upgrades.

Another developer claims to have problems installing VB6 Service Pack 6 on Windows 10.  They tracked it down to two Registry keys not being written.  This website gives a process to install VB6 in Windows 10.  The fact there is now a procedure to install an old app on a new operating system should be pause for concern.

The only way to get hold of VB6 is to have a MSDN subscription.  The subscription is $500 so that doesn’t seem like a huge burden.  But then again, remember that Microsoft is not supporting VB6 though the VB6 runtime is shipped with Windows 10.

There are a boatload of VB6 applications still out there so I think support for VB6 will be around for a long time.  In April, 2014 an InfoQ article  stated there were hundreds of VB6 developer positions listed on Dice and Monster.  VB6 officially went out of support in 2008 so good luck finding entry level and even junior developers to fill those spots – no one is learning VB6 any more.  One of my old clients has had a revolving door of VB6 developers for several years now and it’s getting harder and harder to find competent VB6 developers, and developers that wish to work with it.

As a Xojo consultant we’ve converted quite a few VB6 apps.  Well, convert is a strong word, really it’s a rewrite.  Despite both using a BASIC-like language, the two languages are diverging rapidly (not that they were ever really all that close to begin with).  Many issues that we spent a lot of time working around in VB6 just don’t happen in Xojo.  In our experience entire modules and classes just disappear because we don’t need them in Xojo.

Xojo is updated several times a year while VB6 isn’t.  Xojo is about ready to release a new version that creates 64 bit versions of Mac OS X, Windows, Linux for desktop, console, and web apps.  iOS will also be 32 bit and 64 bit.  VB6 is stuck building only 32 bit Windows apps.

Is Xojo a perfect alternative for VB6?  No.  It is not perfect for every application.  Because its strength is really cross platform applications there are compromises all over the place.  If you look at Mac and Linux applications they just don’t have the complex controls that Windows does.  For some this is a deal breaker because their application demands it.  However, if you want a Mac OS X or Linux version of your application you’ll want to redesign the UI anyway.

Ten years ago our clients came to us for Windows apps first and if we could do a Mac version for the graphics geek that was great.  Now, they come to us for Mac apps first and if we can do a Windows version for the accountant in the corner that’s great.  Xojo does web apps now and that’s become an increasingly larger portion of our business and VB6 just doesn’t compete in that area.

The Xojo universe is full of VB6 developers and the Xojo forums are full of them.  The developers that have found and started using Xojo usually go through a short learning curve and a few WTF moments.  And then, after they stop trying to make Xojo work just like VB6, they embrace the tool and enjoy life again.

Windows 10 is yet another bullet dodged for VB6 hold outs.  At what point do you start to panic and find an alternative?  I guess if you’ve waited this long you’re hoping that Microsoft keeps supporting the VB6 runtime forever.

I am biased, naturally, but Xojo really is a good product and a good solution for many applications.  If you would like to find out some rough costs of moving your application to Xojo we have a utility that will give us some metrics on your VB6 project.  It can be found at

Happy coding!

Licensing Systems for Xojo Applications

For years we’ve been using eSellerate for purchasing and licensing and registration of our apps.  We’ve recommended it to clients too and, for the most part, it’s worked quietly, steadily, and hassle-free for many years.  Their plugin is still using the old Real Studio format and they’ve said in several emails that they will not support Xojo going forward.  With Xojo moving to 64 bit in the R3 release it’s time for us to look at alternatives.

We liked eSellerate for a number of reasons.  For one, it was pretty simple.  Once you learned the intricacies of their web portal it was easy to add products.  Their sample app sucked but we figured out a better sample and offered it as an example for others on our website.  After years of using them I could set a new product up in as little as five minutes.  Then, they handled all of the various sales taxes and VAT for the states and countries that need it.

After the purchase, eSellerate would send an email to the user with purchase details.  This included license code, download instructions, and any other messages that we wanted to give them.  And all of this without any intervention on our part.  It just worked.

eSellerate also has an in-application purchase which we found to be pretty useful.  Users could purchase the application without ever having to leave the application.  For some people this was a nice feature but I’m not sure how necessary this is any more.  Lot’s of people purchase things over the internet with no qualms.

When it came to the registration part of things they had a number of nice features.  I could control how many machines could be activated with a single license.  This led to some instances where users didn’t deactivate a license on an old machine and couldn’t activate it on a new one.  However, a 30 second trip to the eSellerate web portal usually solved this.

On very rare occasions we’d get a user that couldn’t activate an app because of security restrictions on their network.  To solve this eSellerate had a manual activation process that would bypass all of that.  It was kind of tedious but then that’s why it’s called a ‘manual’ activation.

Bundling products together was pretty simple and even setting up payments to a third party was easy.  It was flexible and I know it was used in a number of bundle offerings over the years because of its simplicity.

So now we are on the hunt for the next purchasing/licensing/registration system.  We could write our own but I really don’t want to do that for a lot of reasons I won’t go into here.  Ideally, we’d find an existing system that integrates into our website that takes a variety of payment types and also handles sales taxes.  The last thing I want is to get hounded by a government entity – I just want that to happen automatically.

I’d also like to keep the per machine registration with restrictions on how many activations a single license can do.  It must work on Mac OS X, Windows, and the most popular Linux distributions.  Not that we have a lot of Linux applications but we have some and I don’t want two different systems if I can help it.

The in-application purchase and registration was nice but that’s not necessary any more.  I think most people are comfortable now buying over the internet.  However, offline activation is still something that is a requirement.  There’s no telling where customers are and what security restrictions are in place.

I guess the other part of the equation is that I, nor or customers, need something them an arm and a leg.  I’ve see a few licensing schemes that want $300 per product per month.  While they seem really nice, that’s above and beyond what we want and need.

A few names that have come up recently are LimeLM, Paddle, FastSpring, and I suppose even the venerable Kagi is in play.  FastSpring is more of an eCommerce front end so what are you using for application licensing?

What I’d like, Dear Readers, is for you to share your experiences, both positive and negative for any of the services listed.  Have any missed any that should be on the list?

Xojo and UTExportableTypes

The folks a Ohanaware wrote a blog post a few days ago that all Xojo developers creating Mac apps should read since it involves the UTI (Uniform Type Identifiers) created for your Xojo applications for Mac OS X.

The basic summary is that there is a bug in the 2015 R2.x series (possibly older versions are affected too) that can mistakenly lump all of the UTI’s into the Exportable Types that goes into the application’s plist file. This error can cause the Launch Services database to get corrupted and in Ohanaware’s case, prevented Quicklook from previewing PDF’s.

Thankfully, there are some simple things you can do to prevent this from happening. The first and best solution is to open the FileTypes Editor in Xojo and make sure its settings are correct. Under Build Settings in the Navigator choose OS X. Then press the File Types button that’s in the Inspector. This opens the Editor. The checkboxes on the left should ONLY be checked if your app is creating the file otherwise those files will get lumped into the Exportable Types.

Screen Shot 2015-09-30 at 9.14.09 AM

At this point I’ll take a step back and let you know that I’ve never even really thought about this editor – ever. The user interface is very simple but it lacks information on what these things do. The heading on the dialog does say “Select which file types your application will accept as file drops under OS X” which is pretty clear. However, as Ohanaaware found out it’s exporting it incorrectly.

I did a quick search in the Xojo User Guide and there is a brief blurb describing the roles in UserGuide-Fundamentals PDF. Otherwise, I’ve been unable to find any documentation on the exact use of this dialog.

The second method of fixing this problem is to use App Wrapper utility. This Ohanaware utility has been around for a few years and is a great way to code sign your applications as well as get all those little nasty bits set in your application for release. Have a Retina capable application? It can verify that the assets are all there. Releasing for the Mac App Store? It can help you set the entitlements and also strip your project of verboten items that will cause automatic rejection. And now, after their experience, version 3.4.1 of App Wrapper will do check these settings and can move them from the Exportable Types list to the Importable Types (which is what they should be doing).

Because this was such a disastrous problem Ohanaware also released a free utility called “Preview Reset” for Shine customers that were bit by this bug. I’ll give Ohanaware credit for owning up to it and working diligently to find the solution.

Ohanaware reported this bug to Xojo: <feedback://showreport?report_id=40907>. The good news is that it’s marked as fixed and should be in Xojo 2015 Release 3. However, it’s still in beta so until it’s released take extra special care with your Mac builds.

XJ Bundle

Generally, I’m not a big fan of bundles.  This is usually because they include a bunch of apps that I don’t want or need.  The XJ Bundle is the exception.  This bundle is full of useful utilities and source code for Xojo developers.

Arbed is an advanced editor for Real Studio and Xojo projects.  It has a number of really cool features that the Xojo IDE does not have.  We already own this and use it quite a bit for Localization projects where it scans the project for strings, pulls them out, and makes dynamic string constants for you.  This one feature has saved us hundreds of hours of work.

dtPlugins is a set of Cocoa controls for Xojo Mac desktop apps.  A note on the forums has indicated that the dtPlugins iOS license is also included.  The iOS package has 15 controls and quite a few useful classes for iOS.  This package is on my short list of things to buy when we start doing more serious iOS work.

HTML Edit is a styled text editor that uses HTML for input and output.  It mimics the TextArea control so it should be familiar with users.  If you need to edit HTML this might be a good package for you.

Lexing Control is a plugin that highlights syntax for a variety of programming languages.  If you’ve ever wanted to create your own code editor, this is a good place to start.

Retina Kit 2 lets Xojo developers prepare their apps for Retina displays.  Instead of learning all the declares for Cocoa that allows high resolution imagines, Retina Kit does all that work for you.  Doing cross platform?  No problem because Retina Kit also includes fallback code for Windows and Linux.  We already own this kit and use it in quite a few projects.

RubberViews is a interesting toolkit.  It maintains the place and relative size of every control when its window or container is resized.  The content of that control is resized as well.

TreeView is a hierarchical view control that replaces the built-in Xojo listbox for desktop apps.  It also works in web apps where the Xojo listbox does not support hierarchical lists at all.  We already own this product and can say that it works well.

By themselves these are all good product.  Will everyone have a need for all of these products right away?  No, of course not, but they are useful to have in your stable of tools because you never know when you’ll need one of them.

For $79 this bundle is quite a bargain.  I purchased mine this morning.  I already own some of them, but the price is right and I could see myself using some of the new ones in upcoming projects.

Having the Same Object Handle Multiple Tasks

It’s often tempting to write some code to do a task and make it generic enough to handle similar but different tasks.  A great example that we dealt this this week was a picker dialog that was used generically for people, organizations, and skill sets in a Xojo web app.

It made sense.  The dialog is called from multiple places and it does the exact same thing in each place (displays a list and the user can filter on the list).  What’s different is what data we pass into it for initialization and what data it loads for display.  We wanted the exact same UI in all three cases.

We all want to write as little code as possible.  That’s what’s great about being a lazy programmer.  Do more with less.  That works until it doesn’t and, to be honest, we’ve learned, the hard way, that sometimes the best approach is to make your objects do one thing and one thing only.  Why?  Because inevitably the client will say, this is great, but we want to filter for ‘x’ on people, and ‘y’ on organizations, and neither of those things are interchangeable UI-wise and neither x nor y make zero sense for skill sets.

The first approach is to put lots of if-then-else blocks into what was once a very generic picker dialog.  Now it’s a complex UI that has three distinct code paths.  This complicates testing since every time you make a change it now has to be tested in all three areas.  What worse is the code becomes complex and if you’re in a hurry (and who isn’t?) it’s easy to change the WRONG bit of code.

Our solution was to write the first dialog, get the UI working properly, and then duplicate the entire object and customize it for its new task.  <Gasp>  I know, bad OO programming, right?  We disagree and that’s coming from the school of hard knocks.

The end result is that we have specific pickers for people, organizations, and skill sets.  It’s now simple for a developer to make a change for the picker in question.  No longer do they have to think, “gee, which datatype am I fixing this time,” and possibly get it wrong.  Keeping it simple reduces accidental coding bugs and it reduces unintended bugs due to code changes.

Testing also becomes easier because if we’ve done something to the employee picker, we don’t have to test organizations or skill sets.  Likewise for the other two areas.  Simple is good.

The one area that it does become a bit messier is if we have to do general user interface overhaul.  Now you potentially have three places to do it.  However, since we have WebStyles with web apps this becomes trivial unless you’re rearranging UI elements.  Xojo Desktop apps are a little harder since there are no styles but in those cases it’s actually fairly easy to copy/paste UI from one form to another (assuming that’s possible).

Call me cynical, but I would gladly work on UI for an hour to ensure they’re identical to futzing around with code in three separate code branches that are nearly identical.  I am a lazy developer after all.

Our experience says that generic, reusable objects, often lead us into trouble, so we tend simply not to do them.  But how do you teach that to a new developer and one that’s trying to do their best to use good OO conventions?  And when do you reach that breaking point where the generic way makes it harder than its worth?  Good questions that I don’t have good answers for.

Happy coding!

You Don’t Need to Be A Rock Star

I have been a Xojo consultant for nearly fourteen years.  It’s crazy to think it’s been that long and it’s sometimes hard to remember back to the early days of how I knew nothing and didn’t even realize that I knew nothing.

It also tickles me to no end that people consider me an ‘important’ person in the community.  Some might even consider me a ‘rock star’.  I claim no fame in the Xojo world other than I’ve stuck it out when many other developers have left the Xojo ecosystem.  Let’s just say that at times I feel like I’m the Last Man (consultant) Standing.

Can you become a Xojo consultant?  Absolutely!  There is nothing special about what I’ve done and you can do it too.  I have an electrical engineering degree so it’s not like I’m an idiot and it wasn’t until I met my wife who happened to be a software developer that I was given permission to change careers.

In retrospect that was the best thing that ever happened to me (besides meeting the love of my life).  I was an uninspiring engineer and I dreaded many of the tasks that I performed on a daily basis.  Software development, on the other hand, inspires me.  I wake up every day and (usually) can’ wait to start coding.  The fact that I get paid to do it is just icing on the cake.  To get paid to do what I love?  Sign me up!

If you know a little bit about Xojo you can become a consultant.  First, ask yourself WHY you want to be a consultant.  If it’s for the money don’t expect it to happen right away.  I think it was two or three years before we really made any money at it.  It took six years before I hired a second developer and ten years before a third and twelve before bringing my wife on as a software developer (she had always been doing those pesky taxes and payroll things that I hate doing).

So if you do become a consultant don’t expect to make money right away.  Or if you do, don’t expect the money to be consistent for a number of years.  Even now we fight with cash flow so it takes some discipline to ride out the really good times when cash flow is great and the not-so-good times when cash flow is poor.

The road to becoming a ‘name’ is not a quick one.  I spent many years in obscurity.  The first developer conference I went to I was a wall flower and barely talked to anyone.  By the third conference I co-hosted a session with another consultant because I didn’t feel like I was qualified enough to do it on my own.  Now I’m a regular presenter at the developer conferences.

One way to become a recognized name in the community is to teach others.  I’ve written a fair number of tutorials and example projects and I decided to doing video training and so far I’ve got about sixty-two hours of video available for streaming (and offline use now) with hundreds of individual videos and project files for new developers to learn from.

I think this is the part that makes people think that I’m a ‘rock star’.  I get people coming up to me all the time at conferences and engaging me in conversation and thanking me for some forum post, tutorial, or training video that made a difference for them.  It’s gratifying and sometimes a little scary (as an introvert) to have people do that.

Here’s my dirty little secret on those tutorials, example projects, and training videos.  Those are my way to learn something about Xojo and leveraging that experience for others.  Put another way:  The best way to learn something is to teach it to others.  If you are not doing something like this (maybe not for sale but for yourself) you should be.  That’s the only way you’re going to learn parts of Xojo you don’t know as well.  You really don’t want to learn new stuff on client projects (though it does happen occasionally).

As a consultant I don’t know everything.  There are still things that I’ve never touched in Xojo and things that I touch so rarely that I have to go relearn it.  Those small projects become invaluable review later on.

I don’t want to discourage anyone from becoming a Xojo consultant.  It’s not an easy road at times and it is sometimes frustrating and you put in long hours and you deal with bad clients and all the really bad things that come with consulting.  But the money can be good, it can be fun, it can be rewarding, and some clients you’ll be friends with for many years.  If you love, truly love, coding and enjoy the mysteries of it and putting the pieces of the puzzle together then maybe you, too, can become a rock star consultant.

Happy coding!