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 that’s not a business I don’t want to be in.  Ideally, we’d find a 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!

The Good, the Bad, The Ugly of Deploying Xojo Web Apps

It’s been a very busy first half of the year at BKeeney Software.  We’ve just finished up three medium sized web apps.  One was deployed to Windows Server, one deployed to a Linux web server, and the last to Xojo Cloud.  We’ve done a couple of small web apps to a Xojo friendly host too.  I will describe our experiences below.

Windows Server

The first project was a CRM project where we converted a really old MS Access and ACT! system to Xojo.  The UI wasn’t all that complicated but the data conversion was a pain since it was so dirty.  We ended up using a MySQL database server.

Since we didn’t want to go through the hassle of getting an IIS server we made the decision to deploy as a standalone app.  The hardest part of the whole installation was figuring out how to create the service.  We ended up using NSSM – the Non-Sucking Service Manager to create the service.  After that, installation and updates were a breeze by simply stopping the service, changing the files, and restarting the service.  We are able to VPN into the server and copy the necessary files over.

The server was virtual and running on a VMWare server.  Despite our specifications the server was set up initially with a single core (virtual) processor.  Performance all the way around sucked.  We complained, the client complained, and as soon as they upped it to dual core processors (as we specified) everything went smoothly after that.

Xojo Cloud

The second project was another CRM-type project though a little smaller.  It was using an SQLite database.  We converted the data from a FileMaker database.  The data was much cleaner and more straightforward so it was a relatively easy transition.

The client decided to host on Xojo Cloud so deployment is done from with the Xojo IDE.  The only file we didn’t deploy via the IDE was the database itself which we transferred via SFTP to the appropriate shared document directory on the Xojo Cloud server.

Xojo Cloud, for the most part, works flawlessly.  There have been occasions, however, where it fails to upload properly.  It’s a frustrating experience, to be sure, but Xojo customer service has always been able to fix it.  When it happens on a weekend you’re kind of out of luck.  Here are a couple of suggestions to try and get around the issue:  1)  Restart your server via the Xojo control panel.  2) Change the application ID of your application and try uploading again.

Linux VPS

Our third application has been around a while but we switched over from using SQLite to MySQL after our little db reached about three and half million rows in single table.  It still worked but some of the queries were taking *minutes* to complete.  The decision to move over to MySQL wasn’t a hard one.

You’d think that updating an existing app would be easy.  This one turned out to be anything but easy.  Since this one bites a lot of people deploying Xojo web apps to various Linux distorts it’s worth writing them all down.

  • Until Xojo web apps are 64 bit you’ll have to make sure the 32 bit compatibility libraries are installed.  Each is different so it’s ‘fun’ finding them.  Honestly, check on the Xojo forums to see what people have found.  Hopefully, this becomes a non-issue with Xojo 2015 R3 being scheduled to compile 64 bit apps.
  • Make sure permissions are 775 for all files and directories *including* the overall directory.  The latter one has bitten me more than once.
  • Make sure permissions for the config.cfg file is 664 or 666 (I’ve seen it both ways and I’ve never had a problem with either one).
  • Make sure the owner and group of the files matches that of the system.  If you’re FTP client shows owners/groups and it says something like “mixed” you’ve got a problem.  You’ll need to figure out how to change the owner/group on your own.  This may involved getting SSH access.  It may be easier to work through the CPanel File Manager to upload files because you’re guaranteed, then, to have the right owner/group.
  • Make sure the .htaccess file has been uploaded.  Since it’s a hidden file on Mac OS X it’s easy to miss this one.  If you zip the output directory and then upload the zip it will be there automatically.  If you’re zipping the contents of the directory don’t forget it!
  • Does the server have libicu installed?  Xojo 2015 R2 requires libicu and if you don’t have it your app will just crash with maybe an obscure error in the error log like “Can’t find missing file.”  I had this happen to me this week and when I reverted to 2014 R2 the app started up right away.  If you suspect you’re missing a library and have SSH access, try starting the app via the command line.  It will tell you what the missing library is.  You don’t always have SSH access so that’s kind of a drag.

Not really an issue with web app deployment, per se, but it’s an issue we deal with quite a bit.  MySQL on Mac OS X doesn’t care what the case is of a table or view.  tTable (mixed case) is the same as ttable (all lowercase).  On Linux and Windows this does not appear to be the case.  I know there’s a system variable that can turn this on or off but for this project the client had existing databases on the server and I really didn’t want to muck anything up on them.  Many queries that were running great on our local (Mac) system were not on the server.  Switching everything to lowercase isn’t a big deal (especially with ActiveRecord) but some db apps this will be a nightmare.  So don’t forget to test!

1701 Software Inc.

We have deployed to 1701 Software several times in the past six months for ourselves and for various clients.  We’ve found their servers to be Xojo friendly from the get go (not so with most hosts) and their service is excellent.  They also offer a number of database options that Xojo Cloud does not like CubeSQL and Valentina in addition to MySQL and PostgreSQL.  Frankly, the fact that they are Xojo developers too makes them the top of my list of non Xojo hosting services.  Their prices are pretty good too for those that are price conscious.

That is our experience with deploying Xojo web apps in the past six months.  When everything works right it’s incredibly easy.  When it doesn’t – well, you tend to swear like a sailor.  Hopefully you’ll find this guide to be somewhat useful.  Anything I forgot?

Happy Coding!

[Edit:  Updated to not include an implied timeframe for the R3 release.]

The Power of Small Projects

I am often working in very large projects that I didn’t do the original development.  Other Peoples Code (OPC) projects present a lot of challenges because not only do you have to find the section of the project where an issue exists, but find it in the workflow of the product.  This can be an exhausting process for some OPC projects.  Perhaps you have to connect to a database server (and set up all of the security to do so), submit a query, download some data, interface with some hardware, and then navigate through the user interface to find the particular thing you’re working on.

I was doing this in a recent project and I wasn’t quite sure what the original developer was trying to do (because it lacked some necessary comments) and my iterative changes were taking too long to test.  The debug cycle was easily 45 seconds just to tweak a simple constant and that was taking too long.  I had to come up with a better solution.

What I ended up doing was taking the classes in question and put them into a much smaller project – a demo project, if you will – so I could work with it without having to go through the application GUI.  I was able to control the environment so I could get to it in just a few seconds rather than having to wait almost a minute.

It quickly became obvious what the solution was and I ended up fixing the issue in just a few minutes.  Putting those changes back into the original project was a trivial task.  I ended up saving time, overall, by breaking the code out into a smaller project.

You would be surprised at how often I take a step back from the large project I’m working on to create smaller projects.  My hard drive is littered with hundreds of small projects to demonstrate a technique or proof of concept.  It makes coding OPC projects much, much easier.

This leads me to my next point.  Write the code in your example projects as if you were going to use it in a real project.  This means having reasonable object names, use your standard naming conventions, etc so you can copy and paste code and you won’t have to rewrite it again.  I can’t tell you how annoying it is to have code snippets with meaningless variable names.  What is i and why are you incrementing it?  It might be obvious but perhaps iCount, or iObjectCount, is more descriptive (and helpful).

I am part of the Xojo alpha and beta program.  When I submit a bug I almost always provide a small sample project demonstrating the issue.  This proves that it’s not my coding that’s at fault (which happens more often than I’d like to admit) and helps the Xojo engineers out by providing a project for them to run.  When they mark it fixed, I can also use that project to prove that it’s fixed.

Stop wasting time by trying to fix code in your big project if it’s taking too long.  Break it out into smaller chunks.  You’ll probably find yourself saving time (and your sanity).

Converting FileMaker to Xojo And ActiveRecord

We are currently converting a FileMaker app to a Xojo web app.  We are about  3/4 of the way through the project and it’s been a surprisingly easy conversion.  Our biggest challenge has been normalizing the database since the original FileMaker developer did some things that were less than ideal.

Hal Gumbert over at Camp Software is starting a series of blogposts on their own transition from FileMaker to Xojo.  It is a recommended read.

One of the big things that many developers want coming from FileMaker and MS Access and other tools where the database is tightly integrated into the development tool is data binding.  It makes for a quick way to load/save data to and from the user interface.  We don’t do data binding and I’ll get into that a bit later.

In Hal’s blog post he goes into the various Xojo options and ActiveRecord is one of them.  I thought I’d spend a little time talking about ActiveRecord to fill you in on what it does.

ActiveRecord eliminates many common mistakes that developers have when creating database applications using Xojo.  How many times have you mistyped a table or field name in an SQL query?  We used to do it a lot and ActiveRecord eliminates much of it.  It does this by creating a NameSpace module and creating a class for each table.  The properties in those classes then map to the field in each table.

A register function for ActiveRecord uses Introspection to ensure you have all of the tables and fields from the database mapped in your classes.  If not, an assertion takes place in debug mode which tells the developer if they’re missing a table, field, or if a field is mapped to the wrong datatype.  This is very handy on large projects where you might be adding a bunch of fields to meet changing conditions and this way you definitely will not forget to add them to the ActiveRecord classes.

Creating the classes can be tedious especially with very large databases.  Our ARGen utility will help generate the classes for your by scanning your database and creating the classes for you.  For some this might seem backwards but we tend to design the database first and then code to it and we find that ARGen does 75% of the repetitive work for us by creating the classes and adding some shared methods to each class that help in queries and finding a particular record.

Once created, using ARGen is fairly simple.  To get a list of records in normal Xojo code you would create a query.  ActiveRecord does something similar using a class shared method.  Here is an example of using the List shared method to load a ListBox:

for each oCompany as Data.T_Company in Data.T_Company.List(sCriteria, sSort, iOffset)
   lst.AddRow oCompany.sCompanyNameCurrent,  _
   oCompany.sStreet1, oCompany.sCity, _
   oCompany.sStateCode, _
   oCompany.sZipCode, _
   oCompany.sCompanyStatusName, _
   oCompany.sAgentName, _
   dim iRow as integer = lst.LastIndex
   lst.RowTag(iRow) = oCompany

Data is the NameSpace and we are calling the T_Company List method and we pass in three parameters.  The first is our search criteria, the second is the sort criteria, and the last is the offset which allows us to ‘page’ our data.  It returns an array of Data.T_Company objects and we simply add what we need to the ListBox and stash the object in the RowTag event.  The best part about this is that AutoComplete in the Xojo code editor will show us the table and field names and we don’t have to remember any of it.

Screen Shot 2015-06-24 at 9.49.32 AM

When we wish to edit the record we grab it from the ListBox.RowTag property and pass it in to our editor.

dim oCompany as Data.T_Company =  lst.RowTag(lst.ListIndex)

dim pg as new pgCompanyDetails

pg.Display oCompany

ActiveRecord doesn’t do data binding.  We simply don’t find it useful for a variety of reasons.  First, to do data binding your need to have controls that can handle the data source.  We could create control subclasses but after working with custom data bindings in Xojo on a project or two I was not happy with the endless tweaking we had to do to get them to work properly.  Maybe someone with more patience that I do will be satisfied with it but I never was.  Plus, most developers I’ve met that have done data binding on large projects remain unsatisfied in some form or another or go to extraordinary lengths to make it ‘easy’ (like having every field be string even for things that should clearly be a numeric data type).

Instead we chose a much simpler route.  In our edit forms we have three methods:  Load, Save, Validate.  We feel this offers us some advantages over binding.  First, everything is local to the window.  We don’t have to go find the subclass that handles the data load, save, and validate.  This lets us customize everything for that particular form.  An example Load method:

Private Sub Load()
   if moCompany.IsNew then
      lblCompanyID.text = "New"
      pmStatus.Enabled = false
      lblCompanyID.text = moCompany.iCompany_ID.ToString
      pmStatus.setid moCompany.iCompanyStatus_ID
      pmStatus.Enabled = true
   //Other code here
   if moCompany.IsNew then
      ccDatePicker1.dtmSelected = new date
      ccDatePicker1.dtmSelected = moCompany.dtClientSince
   txtCompany.text  = moCompany.sCompanyNameCurrent
   ccLastModified1.SetRecord moCompany
End Sub

Right away we can see that what we load depends if the record is new or existing.  Data binding wouldn’t help us there.  Labels and TextFields are the easies to do data binding with but since you’ll need a TextField to do a numbers only field or a date field you now have to create multiple subclasses.  Probably not a big deal but we’ve found it to be a hassle.  Having everything local means we can handle the edge cases with ease rather than having to modify the control subclass that’s doing the binding.

Before we can call our save method we have a Validate method that simply returns true if everything is okay.  If not, it presents a message to the user:

Private Function Validate() As boolean
   SetError ""
   if txtCompany.text.trim = "" then
      seterror "Validation Error.  Company name cannot be blank."
      return false
   if Data.T_Company.IsDuplicate(txtCompany.text.trim, moCompany.ID) then
      seterror "Validation Error. That Company name is already in use."
      return false
   return true
End Function

Then finally in our Save method we load data from the controls into the object for saving:

Private Sub Save()
   moCompany.CompanyStatus pmStatus.RowTag(pmStatus.ListIndex)
   moCompany.dtClientSince = ccDatePicker1.dtmSelected
   moCompany.sCompanyNameCurrent = txtCompany.text
   moCompany.iCompanyEmployeeCount = txtNumberOfEmployees.text.val
   moCompany.SICCode ccSic1.SICcode
   moCompany.sURL = txtWebSite.text
   moCompany.sTaxIDNumber = txtTaxID.text
   moCompany.bInactive = chkInactive.Value
End Sub

Note that our save method doesn’t care if it’s a new or existing record.  Behind the scenes ActiveRecord does the appropriate Insert or Update prepared statements.

Every place where we are editing data we have these three Load, Save, Validate methods.  Everyone on our team knows to look for those so it’s very easy for our team to work on projects collaboratively and know pretty much what’s going on.

Could ActiveRecord do data binding?  Sure.  The classes are open source so feel free to modify them to your hearts content but I truly believe it’s more a matter of the controls being the real pain.

ActiveRecord has a number of events that are handy to use.  We track who created and who changed the records using 4 fields on each table CreatedDate, ModifiedDate, CreatedByID, and ModifiedByID.  We add the BeforeCreate and BeforeUpdate events.  For example, the BeforeCreate event looks like this:

Sub BeforeCreate()
   dtCreatedDate = new date
   if session.oUser <> nil then
      iCreatedBy = Session.ouser.iUser_ID
End Sub

This gets called before we save anything so the class properties get modified before we attempt to save.  In many projects we have an audit trail to know who changed what data so we add the AfterCreate and AfterSave events of Data.T_Company and pass the entire object into the Audit table:

Sub AfterCreate()
   dim oAudit as Data.T_Audit = Data.T_Audit.AuditAdd(self)
   oAudit.iCompany_ID =
End Sub

Then it’s up to the Audit class to query the ActiveRecord class to find changed data and put that into its table.  Again, the code to do this is one one spot rather than all over the project.

I could spend hours talking about ActiveRecord as we tend to use on all of our new database projects.  It speeds up development of database applications.  It eliminates many of the common errors.  It tends to force most database code into the NameSpace classes.  And the compiler can warn you if you’re doing bad things with data.

ActiveRecord is not for EVERY project but we’ve found it incredibly useful in our consulting.  If you dread doing a database project because of the tediousness of database coding then perhaps ActiveRecord is for you.

We recently did a webinar with Xojo on ActiveRecord.  You can view it at  ActiveRecord itself is open source.  ARGen is $19.95.  We also use ActiveRecord in one of start to finish training projects at our training site called Link Share.

ActiveRecord home page 

ARGen home page 

Xojo Training Site

Xojo iOS without Android

I will be honest and say that I did not think that Xojo for web apps was going to amount to much of anything.  Granted, I said this as I was struggling with a beta of the very first release to do some actual production work.  Since then it’s gotten considerably better and more stable and it’s become an increasingly large portion of our consulting work.

I was asked the other day what I thought about Xojo for iOS.  I replied that it’s stable and the community seems to be coming up solutions at a much faster pace than Xojo for web.  But until it starts bringing income into my consulting business I’m hesitant to say much more about it.

Let’s talk about that aspect of it for a bit.  When web came out I immediately landed a few consulting projects which was an awesome (and horrifying) way to learn the new framework.  Here it is roughly six months after release and I’ve only had a few nibbles but no actual projects on Xojo for iOS projects.  This despite the ten plus hours of training video I’ve created for Xojo for iOS.

So it makes me wonder if Xojo for iOS is really going to take off.  Part of me wonders if Xojo misunderstood the market for mobile apps.  Sure, iOS is where the money seems to be, but Android has the marketshare and Windows mobile (whatever they call it these days) just keeps hanging around.  Xojo simply doesn’t address Android or Windows mobile.

I think one could reasonably argue that part of Xojo’s strength on desktop is that it makes decent apps that are cross platform and it doesn’t matter which platform you develop on.  You do have to spend extra time for a Xojo app to be 100% compliant on Mac OS X and Windows (I’ll leave Linux out of the mix since I don’t cater to that crowd) and I don’t think many people would argue that if you were going to make a Mac-only application you might want to stick with xCode and Swift or Visual Studio for making a Windows only application.

Apple and Microsoft will always have the best gadgets and goodies for those platforms.  That’s just a fact.  Xojo is often a compromise of the lowest common denominator between the platforms.  It’s RAD capabilities are important but I’m not sure that I’d give it THAT big of an advantage once you get past the learning curve of all the respective platforms and languages.

Xojo for iOS is nice and works well but I feel that without Android it’s not going to get much traction.  Xojo is known for cross-platform apps yet it only supports one mobile platform.  If you were going to go the trouble of developing for more than one mobile platform wouldn’t you go with a tool that supported more than just iOS?

I mean no disrespect to Xojo.  They’ve accomplished a pretty amazing thing.  They have an IDE that allows you to create iPhone and iPad apps without learning Swift or CocoaTouch.  However, you are limited to developing on Apple hardware (that’s Apple’s not Xojo’s fault) and to do any remote debugging you have to use the iOS Simulator that’s part of xCode.  Just that part eliminates a good chunk of Xojo’s potential market (the Windows and Linux users).

Xojo for iOS works well.  It has good developer community support.  I see no reason why developers wanting an easier mobile development environment wouldn’t choose Xojo except for one thing:  It’s iOS only.

So what do you think my fellow Xojo users?  What do you think of iOS for Xojo?  Is it anything without Android and Windows Phone or is it missing something else?

Capturing Unicorn Tears

I ran across a post on the forums where the developer was asking how to call the Action event of a Pushbutton.  The simple answer is use the Push method.  It simulates the user actually pushing the button with the mouse thus causing its Action event to fire (and on Mac OS X the button actually animates the push – I don’t know about Windows or Linux).  The longer, more nuanced answer, is don’t do that!  It’s a bad idea.  Let me explain.

Let’s start off with a typical development experience.  You’ve created your wizbang new utility.  It starts of simple and you have a simple Pushbutton.  You add the Pushbutton to your window, you then add the Action event and you put your super duper code that captures unicorn tears.  You test and it works great to much acclaim.

Version one goes out the door and users ask for more features.  So you add a PagePanel to your Window and move the existing UI to one of the pages.  But, because capturing unicorn tears is THE feature of your app you add a Toolbar to the window and then add a Button to it.  In the Toolbar action event you need to make the same thing happen that the Pushbutton did before.

At this point you can either copy and paste the code from the Pushbutton Action event into the Toolbar Action event and be done with it.  This is bad because if you change something in your process it has to be fixed in two places.  But you’ve read the documentation and know that there is a Push method on the Pushbutton that allows you to simulate the push and fire the Action event.  This is slightly better because you only have one copy of the code.  But it’s still not great.

The better choice is to create a method that does whatever was in the Pushbutton Action event.  Maybe a method called “Handle_Capture_Unicorn_Tears” is a better idea.  Because then it can be called from either the Pushbutton or Toolbar action events.

I know, this seems like a lot of work, but now version two ships and someone asks, “Hey, wouldn’t it be great to have a keyboard shortcut for getting those Unicorn tears?”  And you say, “Yup,” and proceed to add it to the Menubar with its own MenuHandler.  If you had copied the code from action event to action event now you’d have a third place to maintain it.

Have I mentioned yet that this is a bad idea?  So don’t do it.  I’ve had to fix projects like this where code was copied and pasted each time it was used.  All of them slightly different.  Are there reasons for them to be different in this location versus the other location?  Only the unicorns know and they ain’t telling;  it’s very hard to debug apps like this.

But no, you’ve been trying to be a good developer and know that copy/pasting the exact same code in multiple places is a bad idea.  But you did use the Push method and you now try to call that from the MenuHandler.  Except the window that the Pushbutton resides on isn’t even open yet when you try to Free the Unicorns.  Except that in testing you always had that window open when calling the MenuHandler and now users are reporting a Nil Object Exception and are pretty angry.

I’m sure must be a valid reason to use the Push method.  I just haven’t found it yet in fifteen years of coding Xojo applications.  The Push seems to be the lazy way out when putting the code from the Action event into its own method would be just as easy (and preferable).

Push works for Pushbuttons, but there is no equivalent for it in other controls.  Nothing.  Learn how to call the same method from two places.  It’s not that hard.

I’ll mention a forward looking thing based on Xojo for iOS experience.  In the existing framework setting a controls value via code will always fire it’s action event.  For example, if you set the Value of a CheckBox it’s Action event fires.  In iOS, setting the equivalent Switch value via code does NOT fire its ValueChanged event.  This is on purpose and all iOS controls are like this.  I was told by a Xojo engineer that this will come to the desktop and web frameworks too.  Be warned.

Capturing unicorn tears is cool and I encourage to make such a utility.  Be smart about it and be lazy and not just lazy now but lazy for a year from now.  If you ever have a need to call a control event from another location, make a method and call the method from the spots it needs.

What say you my fellow Xojo maniacs?