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?