Table inspector from 4W

[-= JB =-]

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
>  ___________________________________________________________
>  Ambassador at FourthWorld.com       http://www.FourthWorld.com
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at 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<=-