Table inspector from 4W
ambassador at fourthworld.com
Tue Oct 14 14:58:51 CDT 2008
> 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
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
- 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.
Fourth World Media Corporation
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode