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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
