Volume Number: 13 (1997)
Issue Number: 12
Column Tag: Tools of the Trade

StoneTable

by Edward Ringel

This List Manager replacement offers many advantages to the Mac OS developer

The visual management of list and tabular data is one of the weak points of the Mac OS Toolbox. Although each programmer may have his or her pet peeve about the List Manager, most developers would agree on three substantial limitations. First, and I think foremost, is the 32K data limitation. Although it is possible to write an LDEF to overcome this limitation without too much difficulty, we're still left with the fixed cell size and absence of cell styles. Granted, for some applications, the List Manager routines may be more than enough. On the other hand, for anyone with the need to manipulate larger amounts of data, or with the need to customize rows, columns, and cells, it can be pretty easy to bump up against the limitations of the List Manager.

After seeing StoneTable advertised repeatedly in MacTech and looking at their demos, I thought it might be of interest to the Mac programming community to explore this product in depth, as it is the only (at least to my knowledge) freestanding commercial List Manager available to the Mac programming community. StoneTable is a powerful List Manager replacement that offers many improvements over the List Manager routines. Its current competition lies primarily in some of the components of frameworks and one piece of almost freeware that we'll mention briefly at the end of the article.

I received StoneTable via the Internet, which is currently the normal means of distribution. The archive was about 1 meg. After decompressing the package, I reviewed several different documents and files. There is the usual read me about bugs and the like. This document, addressing version 3, indicated that there were no known bugs. There was a longer document reviewing the changes between version 2 and version 3. Although there was a host of information there about the differences between versions, there was no hand-holding about how to do the conversion.

The primary description of the product is an Acrobat file which is a model for software package documentation. It is clear, concise, and well written. The introduction and general principles of operation are very helpful in setting the "ground rules" for the package. The function nomenclature is uniform, as are function descriptions. The document makes nice use of hypertext cross referencing. I would have liked to see snippets of example code in the function descriptions, but I could also see that as excessively burdensome for the author given that he provided a sample program as well.

The software itself consists of a .h file, a .p file, libraries, procedural code examples, TDEF development instructions (covered below) and a PowerPlant class and sample app based on StoneTable. The package I received had CodeWarrior files for 68K application and code resource (A4) development as well as a PPC lib. The sample programs and projects work under the new CodeWarrior Pro IDE. The sample program is fairly simple and does not show off every last feature of StoneTable. However, careful review of the code definitely will show the programmer how to get started and use the library effectively.

StoneTable performs many, many useful tasks. Obviously, it does everything that the List Manager does. The additional functionality is why people pay money for this product. StoneTable supports tables of data that are greater than 32K in aggregate size. It allows many different cell data types. Text, checkbox, popup menu, PICTs, icons (all sizes), hierarchical lists, and CDEF controls are all supported. A wide variety of style information can be attached to each cell: justifications, font, size, margins, and foreground and background colors are all options. If necessary, the programmer can write a TDEF to support a custom drawing procedure. TDEF's are Table DEFinitions supported by StoneTable. A prototype sample TDEF is provided as part of the package.

Text entry into tables is quite sophisticated. One of the very nice features of StoneTable is in-cell editing, which for some programmers is the holy grail of lists. Cell data entry validation hooks and stubs, as well as built-in validations for numbers, help insure data accuracy. Sort and find functions are provided. Comprehensive control over list appearance and behavior can be achieved with TDEF's and other hooks, stubs, and callbacks provided by the library for the programmer. Many of the appearance services are provided in such a manner so that the end user of the application can easily control list appearance with a minimum of programming on the part of the developer.

There are a host of other very useful services provided. Drag and drop and clipboard management, while not terribly difficult to write, are a nuisance, tedious, and error-prone routines. These two services require almost no programming to implement. Drag and drop services in particular are quite sophisticated and include transfers to and from StoneTable and non-StoneTable applications in either direction. Clipboard information includes all cell data.

The programmer must first create a StoneTable list, and then intercept events directed at the list and allow the StoneTable library to process the event. Table creation is not awful, but requires multiple function calls to set display and interface options completely. This is the kind of situation that could lend itself nicely to a resource that is created by the programmer and then passed to a single MakeTable() call.

To intercept table events, StoneTable requires some modification of the basic event loop, but overall this is not an onerous task. Because many unique services are provided, the program must give the StoneTable library the opportunity to intercept events that are directed at a StoneTable list. This is done by intercepting various mouse clicks and keyboard events, as well as activate/deactivate events, etc. I have lifted, with some modification, the conceptual outline of table creation and a typical procedural event loop from the manual (my apologies to Bill Stackhouse for any corruption or obfuscation.)

//The general outline of an application that uses StoneTable.
#include <StoneTable.h>
...
create_table() {
  ...
  window = NewWindow(...);
...
  new_table = TMX_New(...);
//Create a new table and a ttach it to a window, then set the various options
  TMX_SetOptions(...);
  TMX_SetGrid(...);
  TMX_SetColumnTitleText(...);
  TMX_SetRowTitleText(...);
//Now set the cell data
  TMX_SetCellText(...);
//Now draw the list
  TMX_DoDraw(...); /* set drawIt to TRUE */
  ...
}

//event loop
process_event(event) {
  switch (event.what) {
    case nullEvent:
//Take care of table idle events along with program idle events
      TMX_Idle(...);
      TMX_WhatCursor(...);
      TMX_Where(...);
      ...
    case mouseDown:
//Take care of table mouse down events along with program mouse down events
      TMX_Click(...);
      ...
    case updateEvt:
//Process update events
      TMX_Update(...);
      ...
    case activateEvt:
//Process activate events
      TMX_Activate(...);
      ...
    case keyDown:
    case autoKey:
//process table key events and simultaneously hands off non-table events to the program
      if ( ! TMX_KeyNav(...))
        ...;
    }
  }

StoneTable, like the List Manager, makes the programmer do a lot of work to fill the list. StoneTable does provide one function that will take tab delimited text data and load cells en masse, but other kinds of data must be loaded cell by cell. At first, I thought this was a considerable failing of the product, but as I thought about it more, I realized that it would be quite difficult to automate loading cell data. Similarly, saving a table to a file would require a custom function written by the programmer. This discussion can't help but raise the issue of transferring data back and forth between a program memory structure in which the data is manipulated to a StoneTable structure in which the data is displayed. With correct programming technique, I do not think it would be necessary; StoneTable could keep it all without too much difficulty. These pros and cons notwithstanding, it still might be advantageous to be able to store a StoneTable "persistent object," and this might be a future goal of StoneTable upgrades.

In general, StoneTable calls are modeled after the List Manager calls, so the transition is at least somewhat intuitive. Additionally, the StoneTable PowerPlant object is modeled after the LTable class, also simplifying the transition as much as possible.

Memory needs have the potential to be substantial. Each row and each column, requires about 24 bytes allocated. Empty cells take no memory. Those that have data are stored in a tree structure for quick access. Each allocated cell uses a minimum of about 46 bytes which includes style information for that cell. This uses more memory, but apparently is faster than having the style allocated only if different from the default. Memory is allocated using a memory manager that sits on top of the Mac Toolbox Memory Manager. This internal memory manager allocates memory from large handles. Titles other than default letters and numbers are treated as a regular cell.

Numbers and text are both stored as text as in the List Manager. If necessary, the programmer can store binary data in the cell. Apparently, there have been no complaints to StoneTable about performance due to numeric data.

Judging from the available demo program and the sample program, it's not too difficult to create a very handsome table that is very responsive to user actions. I ran the sample program in 68K mode on my trusty Performa 6200 as well as PPC mode. The 68K mode was adequate, and the PPC program was downright snappy. Given the number of lines of sample code, the control over the list's appearance and the quality of the user interface is very impressive.

Figure 1. Window from StoneTable sample program.

Although I have not made an exhaustive search of the products out there, I don't know of any current, commercial, free standing List Manager Replacement except StoneTable. There is an interesting product called the A list, which is almost free. It has many good features, but does not have the speed or full feature set of StoneTable. From a commercial standpoint, it is not bug free and is not supported in the same manner as StoneTable. In particular, I found the code to be much slower than StoneTable, which would be a serious issue with big lists.

PowerPlant and TCL both have table objects. The VIP-C and VIP Basic products support a grid, which is quite powerful. In all of these frameworks, it would be hard to justify a StoneTable purchase for simple tables. It would be cost efficient, however, to purchase StoneTable for a complex list problem. Both Tools Plus and AppMaker are "StoneTable aware" which makes it much easier to use this product in those environments. I think it would be almost foolhardy to create a List Manager replacement from scratch if you were programming in straight C, Pascal, or C++ without using a framework; StoneTable would be a logical choice.

All in all, StoneTable is a solid, useful tool for table management. Many programmers will not use its full array of functions. StoneTable tables in an application will be well behaved and easy to implement. Some framework programmers may be content to use the "native" table object, but many framework developers may still benefit from using StoneTable's unique features. In particular, in light of the recent price decrease and version increment, StoneTable may warrant careful evaluation. We would be most fortunate if all "niche" products were this good.

StoneTable, version 3.0 $199. Available from DevDepot and directly from the publisher, Stone Table Publishing, P.O. Box 12665, Portland, OR 97212. (503) 287-3424.

StoneTablet publishing has a web site, ftp site, and email address. When you purchase the product, you can join a list to be notified of updates, issues, etc.

http://www.teleport.com/~stack
ftp://ftp.teleport.com/pub/vendors/stack
stack@teleport.com

Demo available at:

ftp://ftp.teleport.com/pub/vendors/stack/StoneTableDemo.hqx

Ed Ringel, eringel@mint.net, is Contributing Editor for product reviews for MacTech Magazine. In his spare time, he is a respiratory and critical care physician in Waterville, Maine.