Brett Handley wrote: >Hi Gregg, > Hi all,
I will try separate route, or we can cooperate. I think cell = face is not bad aproach, if you want to have "full control", or if you think of various handlers. Imagine coloring upon some condition, or maybe even pluggable face feel function according to some condition. That way you could create really powerfull combinations ... As for scrolling - it is not needed imo. Take the top-most pane coordinates as the cropping element. Grid doesn't need to scroll, at least vertically. It is data, which are changing, not cells themselves. Just imagine one bigger data matrix, and your visible grid area is only kind of a subface/magnifier, looking at the underlying cache. So - if someone hits arrow key down/up, page up/down, you go to cache to see if you hava data, if not, you call your handler for refilling the cache from data source. I know the aproach is a little bit complicated, but imo the only way of how to create really powerfull grid, able to browse thru tens of thousands of records. I don't want to see another "toy", which blowns up on browsing thousands of rebol block based database ... I want separate data handling layer/api, with ability to hook into SQL or other data sources ... The grid we use here at work is really cool, but it organises data in columnar data arrays = rebol blocks. I don't like it too much. It is that way to have easier handling of column addition/deletion, drag&dropping, and to easily calculate automatic columns width (pixels) adjustment element, according to the longest text (we can't do it in rebol anyway ...). But that's only the question of appropriate set-of-blocks traversing functions ... well, but that's me, my opinions, my requirements :-) Your grid is very inspiring anyway, and I can't promise anything, as I am currently overloaded with tons of work .... Cheers, -pekr- > >>Yes indeed! I get ahead of myself thinking about when > scrolling is >> >added and you dynamically generate just > the visible portion of the >grid, or the grid is tied > to a data source and you update the >appearance of the > grid as the data changes. > Like I said, *way* >ahead... :) > >I got into analysis paralysis trying to solve that dynamic generation >problem so I decided to write something just to get some movement and, >ahem, to see what issues arose ;^) > >BTW a scrolling grid (no smart logic sorry): > > Rebsite / Code. C. / Grids / LibCat > > http://www.codeconscious.com/rebsite/library-catalog2.r > >The grid so far has given me ideas and has raised a few issues: > >*The "smarts" for handling faces as they come on / go off "stage" >should handle scrolling of the grid and resizing of rows/columns >perhaps through a cache. > >*I'd like to see some easy way to plug in controller(s) for handling >data and validation. A problem is creating/handling data events >generically when you don't know what the cell face is that will >show/edit it. I'd like to avoid forcing a special api/behaviour on the >cell faces, but maybe that is the only way. > >*What is the priority for attributes between row and column or is there >a nice merge policy? > >*My current attibute priority is: more specific = higher priority, but >I wonder if there is cases when you want the reverse or maybe both! > >*Should the attributes of different levels (global,row,cell) be mashed >together to produce a cell face like I'm doing now or implemented as >seperate "layered" faces? Or a combo of this and the last point? > >*The functionality should be seperable so that a given script only >needs a grid smart enough for its purpose. > >Interesting excerice. > >Brett. > > -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
