On Oct 14, 2008, at 12:58 PM, Richard Gaskin wrote:
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:
<http://lists.runrev.com/pipermail/use-revolution/2008-April/
109978.html>
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 groups).
It's pretty much all property-driven, so you can put data into it,
toggle its risizing and scrolling behaviors, etc., with simple
property settings.
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
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
And then my Dynamic Table Field will allow you to edit each item,
copy and
paste to each item and turn each item into as many different buttons
as you
want.
Why doesn't the Rev team take some of these examples and build a
flexible field
that everyone can use. I have heard many people mention they want to
have the
fields improved so it is obvious it would be wise economically to
provide both new
and existing Rev customers what they want.
-=>JB<=-
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
