Table inspector from 4W

Richard Gaskin ambassador at
Tue Oct 14 15:58:51 EDT 2008

Bob Sneidar

 > On Oct 14, 2008, at 11:15 AM, Richard Gaskin wrote:
 >>> <>"
 >> The library itself is functional and being used in a couple products,
 >> but the delay in making it available for others is that it has no
 >> documentation at this point.
 >> When I've asked here previously for those interested in the library to
 >> write me I got a few enthusiastic responses, but admittedly only a
 >> few.  Given the amount of work my clients are asking of me (we're
 >> in the middle of major upgrades to most of the products I manage,
 >> with two new products also in development), documenting lib4WTable
 >> has taken a back seat.
 >> I can try to coerce some time to put together even modest
 >> documentation in the next week or so.  No promises -- I get change
 >> orders coming in for our work from clients with enough frequency
 >> that it isn't possible to make firm commitments on things like this,
 >> but I'll see what I can do...
 > I wonder what the price would be that you would charge to contract the
 > work needed to document lib4WTable? If you could get enough of a
 > commitment from other Revolution developers, I would certainly be
 > willing to contribute just so we can have a working table model. But
 > if it is more a problem of time then of course, that wouldn't help
 > matters.

One challenge here is to make sure we're all talking about the same type 
of table.  There are at least three kinds, as outlined earlier:

Of those, mine is the second kind, a list selector.  It's useful for 
databases, but does not attempt to provide the very different 
functionality of a spreadsheet or other types of grids.

In fact, at this time it doesn't even provide in-cell editing, though if 
I need that somewhere down the road I may add it.  Right now my UIs are 
very heavy in master-detail layouts, so in-cell editing just isn't 
something I need (and find myself frustrated with when iTunes insists on 
allowing it when I just want to double-click something).

What it does provide is a convenient way to have column headers at the 
top which:

- can be resized (or fixed; that's an option)

- can optionally support horizontal scrolling (useful for having more 
columns than can fit on screen)

- clicking on a column header sorts the data by that column, with the 
selection retained after the sort

- the sort column has a sort indicator arrow, and like iTunes the sort 
indicator remains at the clipping bounds of the group, so as you scroll 
for example the sort indicator stays in view until the column is 
completely offscreen (it's a subtle touch, but I rather like it <g>)

It's in two parts:  the object itself is a group which uses a standard 
Rev field for display and buttons and other stuff for the header, all 
bound up in a group for convenient manipulation.  Most of the code is in 
a library, so there's very little code redundancy if you use multiple 
groups (and it lets me fix/enhance it easily without mucking with the 

It's pretty much all property-driven, so you can put data into it, 
toggle its risizing and scrolling behaviors, etc., with simple property 

The resizing of the headers, while tricky with horizontal scrolling, 
isn't magic.  I believe lib4WTable can be a big time-saver over making a 
one-off from scratch, but because it uses Rev's field to display the 
text is has the same limits (on the upside that means it can store up to 
4GB; on the downside it means no independent column alignment at this time).

It serves my needs for list display well, and if it would suffice for 
others I'll give some thought to your question.

That said, at this stage it's not like I can just drop my commitments if 
we can find a way to bring in a larger hourly sum for lib4WTable.  But 
it would help encourage me to reprioritize it a little higher on my 
to-do list of free time activities to know that it'll be worth doing.

  Richard Gaskin
  Fourth World Media Corporation
  Ambassador at

More information about the Use-livecode mailing list