ARGen 3.0

BKeeney Software Inc. is proud to announce that ARGen, our ActiveRecord Generator utility for Xojo developers, has a new major update.  Version 3.0 includes a host of new features including the ability to generate ActiveRecord classes for Xojo iOS projects, the ability to use GUID primary keys, the option to include a database update module, include an audit trail module, and include a UI localization module.  There are also new ways to arrange your user interface layouts that can save you even more time when initially creating a project.  In addition to these major new features, ARGen fixes a number of bugs and provides more enhancements.

ARGen has versions for macOS and Windows.  It costs $99.95 but can be used in limited mode at no cost.  Existing version 2.x users will be provided an upgrade opportunity with a 50% discount or they contact us at support at bkeeney dot com to get an upgrade coupon.

Pricing, examples, and more details can be found at the project homepage at

3.0 Release Notes:


* iOS ActiveRecord!

* Reorder fields in the order they should be displayed. This would work both on List and Edit forms.

* Name labels for generated UI elements

* Switch between horizontal and vertical alignment for UI fields and labels

* Projects can now have individual Namespaces

* GUID support (except for ODBC connections)

* Can now include a Database Update module

* Can now include an Audit Trail module

* Can now include a Localization module

* Warnings for aggregates that conflict with Xojo (note below)

* New database connection window

* New app icon



* Oracle databases are no longer supported



* Add / Edit dialog now shows in web version (#3556)

* Icon now displays properly in alerts (#3474)

* PostgreSQL Views now working

* Control init on add and edit windows

* Preferences now correctly handles prefix and suffix settings

* Selecting suffix no longer causes a compile error

* Confirmation dialogs are now set up properly (#3643)

* MenuBarVisible is no longer false on any template windows (#3475)

* Rescan Schema works again



* Database specific PreparedStatements

* Instances of MsgBox replaced with MessageBox (#3474)

* Enhanced Save() on add and edit windows

* Listbox.Open() now has a ColumnWidths placeholder for convinience

* Desktop projects now created with HiDPI on

* Desktop projects now default to 64 bit for Mac

* Opening a SQLite project automatically attempts to connect (#3596)

* Auto-Generate UI step is now easier to understand

Aggregates Note:

When using aggregate like Count(), Max(), Min() some DBs will return the aggregate as the field name.

Added code to warn on open project that there is invalid for xojo field names, and fail generate. 

RAD Still Means You Have to Learn the Language

Xojo is a great development tool that is a Rapid Application Development (RAD) environment.  That’s marketing speak for you can get stuff done quickly.  The marketing speak isn’t wrong but for many people they think this means that Xojo is ‘easy’ and the learning curve is next to nothing.  I hate to break it to those developers, but it just isn’t true.  Xojo, like any development language has a learning curve.  It might be a lot less than others but there is definitely one.

The truth is that Xojo is RAD once you learn how it works.  This means you have to learn the basics of the IDE, the language, and the debugger.  And only after understanding the basics of Xojo can you start taking advantage of the RAD part.

There are parts of Xojo that aren’t so RAD.  One of those, in my opinion, is database coding.  You still need to know SQL, and use the basic database classes to read and write data into your application.  In fact, it’s so low level that the IDE does not help you, in any way, which may lead to database errors.  The IDE will happily let you try to put a string into a numeric field in the database.  What worse is that depending upon which database is used (looking at you, SQLite) it won’t complain when you do so (thankfully this is not true of all databases).

Putting data into a database using the database classes is a two step process.  One, you have to query the database knowing what the field names and datatypes are as there is no autocomplete for them.  Xojo will happily let you (try at least) put a date value into an integer at design time.  It’s not until you try all this at runtime that things fall apart.  The same is true for updating and inserting data.  These are the reasons why we came up with ActiveRecord – our database classes for Xojo.

ActiveRecord is our way of making the Xojo compiler a little bit smarter.  It maps each table to a class and the properties in that class map to the database fields.  ActiveRecord checks to make sure that all of the fields in the table are represented in the class.  If not it flags the developer.  (It does way more but this post isn’t really about ActiveRecord.)

From our experience, jumping straight into ActiveRecord isn’t all that helpful for new Xojo users.  It’s a shortcut and you’re depending on our code without understanding it and I strongly discourage it until you’ve gone through the pain and tedium of using the standard Xojo classes.  In fact, when we train new developers we ALWAYS have them do a small project using the standard Xojo database classes.

Then we train them in how to use ActiveRecord.  The setup is a bit more involved and it’s not a perfect system, but once they start using the Table/Field autocomplete and having the compiler warn about mismatched datatypes they start to understand how much faster they can code database applications.  We are consultants, after all, and time is money.

Rapid Application Development systems do NOT mean quick to learn and being able to create an application with no experience.  RAD means that AFTER you’ve learned how it works it can be incredibly fast.  Once you learn Xojo is *can* be very fast to develop applications.

Anyone disagree with this?  What is the best method of learning Xojo?  Online documents?  Webinars?  Videos?

Serial Devices as Keyboards – Yuck!

We’ve recently had a number of projects that required the use of a serial devices in desktop applications.  In all cases the clients said the devices are, “easy to use,”  since they act just like a keyboard.  If our experience is typical then I’d hazard a guess that many Xojo developers are frustrated with them.

Several projects required the use of barcode scanner.  Having a barcode scanner work as a keyboard makes sense, I guess.  It means that it can work with literally any application, anywhere, any time.  All it needs is focus on a text field and whatever the scanner sees it puts into the control.

In another project we had an ultrasonic sensor that would take the application out of idle mode and present the user with purchasing information.  Again, it acted just like a keyboard which means it works with any application as long as you had focus in a text field.

If you happen to know WHEN this information is going to come in it’s not so bad as you can plan for it.  Putting the focus in a field and waiting for information is easy.  It’s not so easy when that information could come at any time.  Of course all of our applications had data that could come in at any time and we had to be prepared to act on it immediately.

If you rely on a TextField or TextArea getting this information the rest of your interface can really suffer.  It means that when your barcode/sensor field loses focus you have to get it back (or you lose information).  Do you do this right away or wait a few seconds?  And if you have a complex user interface how do you deal with tabbing between controls, or even simple things like a user changing a checkbox because the focus is lost on your TextField?  It can be a nightmare to try and figure out and get right.  The differences between Mac and Windows and Linux can be frustrating!

The answer that we ended up implementing was putting the barcode readers into serial mode.  I’ve not run into a barcode scanner yet that couldn’t be used in serial mode.  Every scanner has a gazillion different modes and properties (all set via barcode of course) and one of them is to make it appear as a serial device to the computer.  On Windows this is a COM port and on the Macintosh they tend to show up as a USB Modem.  If I had to guess I’d say it’s harder getting barcode readers that are Mac and Linux compatible.

Once it’s in serial mode it’s almost trivial to create a class that monitors the serial port and reads the data WITHOUT needing the focus in a TextField.  The class then distributes the data to the objects that can consume the data.  What I do is have the window or objects register itself with the class and then when the data comes in the class sends it to all registered objects.  Each of the objects has an Interface with a simple HandleBarcode method.  This is known as the Observer Pattern and there’s an example that ships with Xojo.

My ultrasonic sensor wasn’t so easy to overcome as it couldn’t be put into serial mode.  However, it did come with a Windows-only SDK (thankfully it was a Windows only project) and with a little help with Declares we were able to get it working so we could tell if someone had walked up to the device and when they had walked away.  I’m not sure what we would have done if it had been a Mac or Linux project.

Serial Devices are relatively easy to work with in Xojo (as long as they show up in the serial list).  Having to deal with devices that act as keyboards not so much.  I’d highly recommend trying to get them to work as serial devices and save yourself a ton of grief.

What’s been your experience with serial devices in Xojo?

Coding Habits To Keep You Alive When Time Travel Is Invented

When you’re writing code we all know it’s a great idea to use method, property, class, and variable names that make sense.  It also makes sense to add in comments on code that isn’t clear.  But do you code in such a way that your future self won’t invent a time machine and come back and slap you in the face?  This is how you should be coding.  You really want your future self to appreciate the work your current self is doing.

One of the current projects I’m working on interfaces with multiple devices via serial communications.  Each one of them uses a different protocol (naturally) and some of the code was written by me and some of it by others.  Before I get into the Other Peoples Code (OPC) portion I’ll talk about my experiences with coming in cold to something called ccTalk.  ccTalk is a low speed communications protocol for use with Coin and Bill Accepters.

Had I ever heard of ccTalk?  Nope.  So the first thing I did was Google it.  I found a few helpful blog posts on it (saved the links) and found a few projects in Java and in C# and downloaded what I could.  I studied their code.  I found specification documents for ccTalk and device documentation and all were immediately added to the source code repository.  Why?  Because as soon as I move on to the next project I’ll forget the details.  If the information isn’t relevant in two weeks I’ll most likely forget about it.

In writing this post, I came to the conclusion that I also need to add any required drivers to the repository as well.  From experience I’ll inevitably need them in the field and if I don’t have them on hand I’ll waste time searching for them again.  Were they sent in an email, on the packing CD, or available from the website?  If it’s in the repository I won’t have to worry about it!

In my source code I document the message numbers I’m sending to the device and putting relevant details on the response and what I’m expecting back.  For ccTalk this might be a simple acknowledgement/busy response and depending on the command some additional data.  How much data am I expecting?  Did I get less?   Did I get more?  Does the checksum match my own calculation?  Do I have a way to create a log of the communication stream and is that log in human readable form or in hex?

This might seem like overkill but I’ve had to go back to my own code years later and relearn what I did.  This has involved finding the manuals again and trust me that’s no fun.  I think it best to assume you will not be the programmer on this project in the future.  Perhaps you get hit by a bus tomorrow and your client has to find a new developer.

The OPC portion of this project is using a different serial port to a different device and has exactly 24 comments in it.  Most of the comments don’t help me.  Commenting ‘If then’ doesn’t help me.  There are a few ‘Return //Exit this Routine’ comments that again would be more helpful if I knew why I have to exit the routine because it’s not immediately obvious from the rest of the code.  There are no comments regarding expected data.  No defensive coding techniques to ensure that if something is missing or garbled it can handle it gracefully instead of just crashing.  Of course there was no documentation for the hardware either so I’m not even entire sure I have the darn thing hooked up properly – all I can do is assume that I did until I get that documentation.  All-in-all I want to jump through the screen and scream at the other developer to a) put in useful comments; b) include the documentation with the source code; and c) include drivers and utilities that a newbie would need!

I try to make sure, in my code, that the developer that looks at my code in six months doesn’t curse me.  I say enough bad things about myself as it is.

What sorts of things do you do to ensure future you doesn’t curse your current self?

Iconographer Review


If you’ve spent any amount of time making cross-platform applications in Xojo you probably hate icons as much as I do.  I’m no graphic artist and because of this I’ve paid good money for several icon sets.  These icon set are fine but they’re pretty basic/generic and don’t tend to look right in macOS, Windows 8 and above, or even iOS.  And that’s just for application icons.  Making icons for documents, disks, folders, and the like, are just as big a pain to make.  Each platform has several different styles and getting it right is awful.

Ohanaware introduced Iconographer last week.  This is the tool I’ve been waiting for!  Iconographer lets you easily make icons that are consistent for their target platforms all while keeping the overall identity intact.  Not having to use a high-end graphic tool, like PhotoShop is worth it to a developer geek like me.

Using it is easy.  Simply drag your starting image into the editor window and start manipulating it.  At the top left of the window there is an expanding toolbar, for lack of a better word, that lets you pick the Icon Type:  Application, Folder, Disk, Document, and Web Icon.  Below that you have options for the target.  Depending upon the Icon Type you have the option to pick the Target.  For Application you have macOS, Windows, and iOS but for the Folder Target you only have macOS and Windows.

screen-shot-2016-11-10-at-7-09-32-pmTo the right of the drawing canvas you can pick the style of the icon.  For macOS you have Blank, Circular, Rounded Rectangle, Tilted, Rounded Square, and Plugin.  For Windows you have Blank, Windows Tile, and Use Different Application Icon.  Similar styles are there for iOS.

Below the Styles is the Layers list that lists the layers in the selected Style.  I will be honest, I had issues figuring out how to manipulate the layers.  You can add layers using the ‘+ Layer’ button where you can add Shapes, Images, and Text.

Adding Text also was problematic for me.  Once I added a Text object I couldn’t always select it until I had rotated it and then reset it to zero.  Then, if I had two text objects I never was able to edit and change the text of the first one.  I chalk this up to possibly not understanding what the shared label is.  At times I also had a weird purple selection rectangle that I was never able to get rid of.
At the bottom of the drawing canvas is, perhaps, one of the more useful features of Iconographer.  The Eye lets you select from a number of environments to preview your icon in an About Window, the macOS dock, and even the Mac App Store, to name a few.  This is a great way to preview your app in an actual environment and lets you make decisions while in the application instead of having to leave and use a graphics application.

screen-shot-2016-11-10-at-7-09-49-pmOnce you’re done you can build your icons.  It takes the currently selected Icon Type and all of the selected Targets and outputs them into the directory of your choice.  For macOS it will create an icns file and for Windows an ico file.  It really is that easy.  It would be nice to have the ability to export SVG format too.  If you’re creating a suite of icons, say for application, document, and disk, you have to do it in several steps but that I suspect that most developers won’t have an issue with that.

Iconographer is a must have for any cross-platform developer.  It’s ability to make consistent application and document icons for macOS, Windows, web, and iOS easily and quickly make this an invaluable tool.

Iconographer works on macOS X 10.10 and better.  It normally costs $19.99 but Ohanaware has an introductory price of $9.99.  More information can be found at

To Be or NOT To Be

I’m probably getting into quasi-religious questions here, but I’ve been reading someone elses code in an OPC (Other Peoples Code) project and they use a lot of statements like this:

If Not aBooleanValue then
   //do something here

I find this harder to read and much prefer:

If aBooleanValue = false then
   //do something here

I understand why people want to use the former but to me it reads backwards.  I have to flip the value in my mind before the variable and then keep that in mind for the eventual comparison later.

And don’t get me going on people that do things like this:

If Not (SomeFunction > 0) then

//do something here

To me, that’s just being too lazy to correct your code.  What should be explicitly clear is now not so clear (granted, this is a super easy example but you get my point).  I like to code for explicitness which means it’s easier to read (by me or someone else) weeks, months, or years from now.

I’m lazy.  I freely admit this.  I prefer to see the test values explicitly called out.  So something like this:

If aBooleanOne = True and aBooleanTwo = False and aBooleanThree = True then
   //do something here

is better than:

If aBooleanOne and Not aBooleanTwo and aBooleanThree then
   //do something here

For every ‘rule’ of course there’s an exception.  For simple boolean comparisons where I am checking for true I tend to write:

if aBooleanValue then
   //do something here

The True check is explicit and there’s only one variable to compare.  As soon as I use a second variable I will change it to be more explicit.

It’s such a little thing but when reading code one seems much easier than the other.  Or perhaps it’s just my OCD shining through.

What do you think?  Am I being overly critical or do you have similar beliefs?

Microsoft Buys Xamarin and SQL Server Goes Cross-Platform

It’s been an interesting couple of weeks in the cross-platform development world.  First, Microsoft announced that they were purchasing Xamarin.  Xamarin and Microsoft have always been friendly and this move isn’t very surprising.  As a Mac user much of the marketing verbiage doesn’t talk about the Macintosh, just iOS along with Android and Windows Phone and Windows apps.  Xamarin has always seemed to be mobile first and desktop last, so again, this doesn’t seem surprising.

Many people really like Xamarin and there are a number of Xojo developers that have tried it out.  Their opinion of Xamarin isn’t very good:  limited support, expensive, buggy IDE, and slow building of apps are just a few of the major complaints.  In comparison Xojo, they say, is ‘fast and lean’.

This week Microsoft announced that SQL Server, their Windows-only database server will be ported to Linux and be available in 2017.  This seems to be a tacit agreement that their biggest weakness in the server world is Linux.  Linux is extremely popular and since it’s cheaper to deploy than Windows they have to do something to stop the hemorrhaging.  Perhaps they’ll sell a boatload of licenses but it’s tough competing against the free or inexpensive database servers like PostgreSQL.  Again, no where are they talking Macintosh OS X.

This news makes me happy that cross-platform app development is getting some attention.  When the big boys of the world are pumping money into it then there must be something to it.

It also makes me sad since I don’t see Xojo changing their focus.  For many years they have had this hobbyist/part-time developer first mentality.  This has hurt them with professionals looking for a new development tool.  There are many things, I believe, that hurt them in this market.  I’ll list a few here:

  • It’s a BASIC language:  No getting around it.  It’s a modern object oriented language that compiles down to native code, and (mostly) uses native controls doesn’t seem to matter much.  VB6 screwed up many peoples opinions of language for better or worse.  In reality, there are lots of really good VB6 apps out there but many more poor VB6 programmers.
  • The IDE: especially the Code Editor.  It doesn’t let you do bad things and that’s great for beginners.  Usually it’s the first thing people complain about, though.  It’s limiting, and forces you into the Xojo way of doing things.  No other major IDE, that I’m aware of, forces this restriction upon their users.
  • Lack of basic controls:  I’ve been using Xojo for 15 years and have a tool chest of controls and libraries that I use on a daily basis.  But still, the lack of even basic Date/Calendar controls is a turn off for many first-time users.  Add in very poor RTF support, no PDF support, and especially no true grid control and you have a lot of strikes against the tool.  Yes, you can turn to the 3rd party community for some of these (and they are not very expensive) but to not have any of these things hampers adoption.
  • Reporting:  I don’t know of any serious Xojo developer using the built-in reporting tool.  It’s just not robust enough for most peoples needs.  We’ve used several 3rd party tools over the years and in the long run wrote our own (BKS Shorts).
  • Android:  iOS was a big addition to Xojo but without Android it’s not convenient to do a lot of mobile development with Xojo.  To add Android is a huge project and unlike anything they’ve done to date.  I would expect a minimum of eighteen months but probably more like two years of major development work to get it into Xojo even as a beta.  And that’s assuming they announce it.

I use Xojo all day every day and use it for dozens of commercial desktop applications and dozens of Xojo driven web apps.  Xojo is mostly stable and under constant development.  Just in the past year they’ve added iOS and Raspberry Pi development as well as added 64 bit compiling for Mac OS X, Windows, and Linux.  Much of the limitations you can overcome by dipping your toes into the 3rd party market – but that market is tiny in comparison to many other development tools.

So my wish is that Xojo would focus more on business needs.  Identify the features that business owners need and implement them.  Include more basic controls and charge more for advanced controls that not every developer will need.  Get reporting cleaned up.  Make database programming smarter and less error prone.

It is my firm belief that if you get the business users you’ll capture the part-time and hobbyist programmers along the way.  Many of the hobbyist and part-timers only care about one platform and that’s only a $99/year investment.  If you want to do cross-platform desktop that’s only that’s $299/year.  For every desktop license you need three single licenses.

A Pro user like myself needs desktop, web, and console apps for sure.  iOS is a nice add-on but not necessary for us at this point.  The Pro license costs $699/year.  You need seven single licenses to make up for it.  My company has four licenses and we renew every year.  So my business is the equivalent of twenty-eight single license users and while I might grumble at writing a check every year for license updates it’s nothing at what we used to pay for VB6 and 3rd party licenses every year.  At one point it was $2,000 per developer per year.  That’s just the price of doing business.

So tell me, which type of customer should Xojo focus on?  What do you think their biggest weakness is in capturing some of this nascent cross-platform market?

Shorts Report Designer 1.5.3

We released version 1.5.3 of BKS Shorts today.  A number of bug fixes, changes, and additions were added.  The change list below.

I will be the showing off Shorts at the next Xojo webinar on February 2nd at at 1:00 PM (GMT-5:00) Eastern Time (US and Canada).   Signup at

One of the new items is the ability to show a Row Number on any band using the new SC_GetCount XojoScript.  Add this to any Band Script to modify a TextItem.

We added a couple of new examples based on user feedback.  The first is using the SC_GetCount Band Script to set row numbers.  The second, is an example of how to print directly to a printer without having to go through the viewer.

Change List:

  • Added SC_GetCount in the Band XojoScript editor. This lets you get how many times this band has been shown.  Example of use is to have line numbers on your report without having to do it in SQL.
  • Updated German localization
  • Rearranged UI on ccPAF_Filter (Filter Data) to make it a bit more obvious
  • As a Text Item or Field Item are put on a report it will automatically use the “Default Style”
  • Fixed an issue where the Default Style wasn’t getting passed to the generated report.
  • The Styles Editor now allows you to delete multiple Styles at a time.
  • Added a new example of how to print directly to printer without having to use the viewer.
  • Reconfigured Demo window to break between Report Designer stuff and older code-only stuff.
  • Added SC_GetCount Demo
  • Fixed some items in the HTML Renderer
  • In PAF_PrintKit.PrintText.constructor if there is no DefaultStyle we create one.
  • ReportPF will now extract Styles from the report definition file.

BKS Shorts with the Report Designer is $300 and you get the full source code.  More information can be found at


Implicit Instance is Evil

Xojo has had Implicit Instances of Windows and WebPages from the very beginning and I was so happy when they gave us the option of using it or not.  I can tell you from experience debugging newbie apps that Implicit Instance is evil because it often leads to subtle and hard to find errors.

The implicit instance lets us do some very simple things like:

Window1 is shown.  No big deal.  For simple apps this is no problem and fast and easy.  That simplicity comes with some perils because window1 loads whenever any control or property on that window is checked.

For example, a lot of developers will do something  like this:

window1.close //close the window

if window1 <> nil then
   //Window is open.  WTF!  I just closed it!

The problem is that simply by doing this comparison, window1 is loaded into memory and depending on the other window settings it may become visible.  It drives developer crazy.

Setting ImplicitInstance = false forces the developer to make a new instance of Window1 if they want to use it:

dim w as new Window1

I think this is the preferable approach because it’s safer.  It will never give you Window1 by accident.  In fact, if you attempt to do this with window1.implicitinstace = false:

if window1 <> nil then
   //Do something.

The Xojo compiler will give you an error that says:  Expected a value of type class Window1.Window1, but found a static namespace reference to class Window1.Window1.  This is a roundabout way of saying you can’t call window1 directly since that’s the class name when in reality you need to be checking for an instance of the class. That class instance cannot be named Window1 (because that’s the class name).

So how would you check to see if a Window is already open?  That’s easy.  The Window and WindowCount methods are there for you to do just that.  Iterate through the window listing and when you use the ISA method to ask if it’s of type Window1.  If it is, then do something.

  for i as integer = 0 to WindowCount-1

if window(i) isa Window1 then
   //Do something with the Window1 instance.
   //You have to cast it as Window1 from the Window method
   dim w as window1
   w = Window1(window(i))
   w.someproperty = false //set a public property
   w.LoadNewData //call a public method //brings the window to the front


A common thing to do is close all instances of a particular window.  Using the above code might fail if you have multiple instances of a window open.  Here is the code that closes all instances of a type of window.

  for i as integer = windowcount-1 downto 0

if window(i) isa Window1 then

In this case we must iterate backwards through the array.  Think about it if you are confused as to why.  Better yet, test it yourself.

Web apps have a similar property in the WebSession.PageCount and WebSession.PageAtIndex methods.

  for i as integer = 0 to session.PageCount-1

dim w as WebPage = Session.PageAtIndex(i)

if w is a WebPage1 then
   //do something with WebPage1


The drawback, if you can call it that, to having Implicit Instance = false is that as you call new windows or web pages you haven’t done anything to the old ones.  Depending upon your application this may cause long term memory issues especially as the app gets a collection of pages that are no longer used.   For short lived apps this usually isn’t a problem.

To solve this you can either iterate through the existing windows/pages to find the one you’re looking to reuse or simply close it as you open your new one.  Either way, I don’t think the burden is too high.

It is my not-so-humble opinion, that leaving ImplicitInstance = true is bad for you as a Xojo programmer.  Simply put, Implicit Instance is evil and you should avoid using it – especially in larger applications.

What say you my Xojo developers?    Do you like to turn Implicit Instance off or do you even care?

Listbox and Tag Options

The Listbox is a very powerful control, in my opinion.  Out of the box it doesn’t have a lot of capabilities but it’s easily extendable and it’s possible to create some complex grid-like applications using the standard Listbox.  Is it perfect?  No, but it’s more than adequate for most developer needs.  There are a number of options for showing and storing data.

A new user to Xojo recently asked me about the various tag options in the Xojo Listbox.  She wasn’t sure when you’d want to use RowTag versus ColumnTag versus CellTag.  It was a good question – I hadn’t given it much thought.  I like questions like this because it forces me to think like a new Xojo developer.

Most Tags in Xojo are the Variant datatype and that means they are very good at storing whatever you want in them.  We often say, “just stash the data in the tag”.  Since you can put practically anything in a variant it’s very convenient to use it.  I suspect that whenever the new framework makes it into UI elements the tag will turn into an Auto variable (which will lead to interesting problems but that’s a post for another time).

When it comes to the Xojo Listbox, I know some Xojo developers like to make columns of zero width and put data in these hidden cells.  I dislike this approach for several reasons.  One, it limits what the listbox GUI can do.  A zero width column means that you probably don’t have column resizing on (and if you do the columns are accessible to the user).  Two, it’s not how the control was intended to be used.  Three, we have Tag options to eliminate the need to do this.

We predominantly use the Listbox.RowTag property to store our data.  A vast majority of our projects are database driven and since we use ActiveRecord a lot we almost always have a class object (the ActiveRecord object) that has our record stashed away in the RowTag property.  The listbox may only have 2 or 3 visible columns of data but the ActiveRecord object might have dozens of properties (which reflect the fields in the table).

This gives us the advantage that we only have to query the database once and that’s to load the listbox.  Subsequent edit/update and delete operations simply use the object that’s already in the RowTag.  The user selects the row, we get the object out of the RowTag property and then pass it on to whatever method needs to work with it.  This fits 95% of everything we ever do with a Listbox.

The CellTag comes in on projects where we’re not using ActiveRecord.  Things like preferences come to mind where it’s data but not database related.  We load the Listbox cell data with what the user can edit.  Then, in the CellTag property put a copy of the visible data so later on we can compare the Cell text to what’s in the CellTag.  Even in this case, though, we still use the RowTag property for identification purposes.

Using the CellTag and comparing it to the Cell text is convenient when doing inline-editing of the Listbox data.  The comparison can happen at the Cell Lost Focus event or in a generic Validate method before saving the data.  Either way, the CellTag data is ‘hidden’ and the user can’t mess with it.

The ColumnTag has been around a couple of years and I can’t say we’ve used it much.  I can see the benefit of using it, however, to make things like Pivot Table using the Listbox.  This isn’t a trivial task, mind you, but I would treat it like the RowTag.  It’s there for use and I’m sure someone out there has a reason to use it.

If you find yourself making zero width columns to store data in your Listbox you should look at the various Tag properties.  Trust me, it will make your application work better and be safer with your data.

What interesting things do you use Listbox tags for?