Table fields... oh boy.

[Richard Gaskin]

Troy Rollins wrote:

> On Aug 15, 2004, at 2:17 AM, Richard Gaskin wrote:
> 
>>> To me, data grids are a pretty critical functionality....
>>
>> For me too, but I think you're talking about a very specific 
>> implementation of a data grid, perhaps the type one sees in 
>> spreadsheets or the type supported by HTML.
> 
> Not HTML. But speadsheets, or iTunes, or many other data grid driven 
> program types.

Spreadsheets and iTunes are very different creatures.

Therein lies the difficulty in satisfying the request:  so many options,
so little specification.

>> The built-in multi-column field has been doing me just fine for years. 
>> You can put up to 4GB of tab-delimited data into it and get instant 
>> results by setting the tabStops property. It supports most of the 
>> behaviors commonly associated with database display, including 
>> properties for selecting either single or multiple lines, and even 
>> discontiguous selection.
> 
> Yes, and I've used those features, and it can work OK, but well, it just 
> isn't powerful enough, and frankly, too flakey, especially if the user 
> is to be able to edit the content. Layout is clumsy...

I'm not sure we're talking about the same things.  Not that what you're
looking for is necessarily trivial, but rather on the contrary: there
are MANY types of multi-column lists, if you observe them closely.
There is no one-size-fits-all.

Some specifics about what you're looking for would be helpful in
providing a solution, but you've already ruled that out: you'll accept
nothing that isn't built into the engine, and no one can build it into
the engine until its details have been specified.

>>> where entire multi-field cards are used instead of a single 
>>> multi-column line in a grid. This is not a workable solution in many 
>>> cases, since it doesn't support relational sorting, etc.
>>
>> What is "relational sorting"?
>
> Column sorting. Obviously cards full of fields do not support column 
> sorting, so I put it into another term. Relational sorting (column 
> sorting) allowing rows to be sorted by the different relationships they 
> have with the columns.

For the rare case like Jacque's grid, which is very different from
iTunes in that it support multiple lines per cell, yes, that's tough.

But for single-line cells the built-in list field will use the built-in
sort command:

   set the itemdel to tab
   sort lines of fld 1 by item 4 of each

>> The built-in sort command will do well with the built-in multi-column 
>> list object, with the only caeat being that no single line of text can 
>> be longer than 64k (which is probably wider than would be practical 
>> for most common uses anyway).
> 
> Yes, I'm sure that is far wider than is needed. But a multi-column field 
> doesn't do a very good job of simulating a data grid. I don't doubt that 
> you have found it OK for your applications, or somehow made it work. In 
> my case, the market particular product will be very critical of this, 
> and anything less than "so good they don't notice anything other than 
> good" is too little.

You seem to be referring to grids in which a cell has multiple lines.
Because this is very different from iTunes, which you also cite as an
example, it becomes difficult to understand what you're looking for.

Given the world of difference between the two I hope you'll forgive the
confusion and, if you'll reconsider the requirement that it be fully
engine-based we might be able to provide what you need once we
understand it.

>>> It isn't an actual OS native grid
>>
>> Where did you get the impression any OS provides a data grid control?
>>
>> If there's a native data grid control in OS X or XP it's very new; for 
>> the previous 20 years everyone rolled their own.
> 
> Well, Applescript studio has one, so on the Mac at least it my not be 
> part of the OS, but it is provided by Apple for constructing UI... I 
> should probably say "one which appears native, matches the rest of the 
> OS, and would be considered by the end user to seem appropriate on their 
> system."

And there's the rub:  we've already identified three very different
types of multi-column lists: spreadsheets, multi-line cell types, and
the more common iTunes style (single-line cells but without the
spreadsheet behaviors), and we haven't really even started examing the
full range of options yet (headers, selection/sorting/binding/resizing
options, etc.).

These are not subtle differences; data grids are inherently complex
objects.  This is probably why OS vendors haven't bothered to make an
API for one.

Consider the many options that go into describing the appearance and
behavior of the many types of multi-column lists in common use.  Then
multiply that by the number of OSes supported and you begin to get a
feel for the complexity of the task.

Specs have been proposed to RunRev for such widgets, and even in their
more focused form, which does not attempt to address all types of
multi-column lists, the number of properties was more than two dozen.

So there are three options at hand:

- Specify what you need and let's see if someone has what
   you're looking for in scripted form.

- Specify what you need and let's see if it could be added
   to the engine.

- Send us a postcard from El Dorado
   (ride, bodly ride, the shade replied...)

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________
  Rev tools and more:  http://www.fourthworld.com/rev