Chris, My name is Pete Davis and I did the grid development in Mozart 1. Dan pointed me to your grid and I've been looking over it (though not for very long yet, so I'm probably missing a lot of stuff).
First of all, I just wanted to offer my assistance if you have any questions with regards to grid type stuff. I haven't done much Java development at all, but I've spent almost 3 years working on the Mozart 1 grid, so I have A LOT of grid experience. I do have some questions and comments on what I've seen so far... It appears you're storing 3 different vectors of selections: Row selections, Column selections, and cell selections. I'm not entirely sure I get how the selection mechanism works. I see the cellSelectionEnabled, so I assume that allows cell selection. Does that also enable column selection? There are advantages and disadvantages to having the selections separate. I know the developers using the grid find it easier to deal with them that way. But there are also some advantages to combining them into a homogenous structure. In the Moz1 grid (and we're using a commercial grid underneath, so we've inherited their mechanism), there's the concept of a "Grid Range" which can be column(s), row(s), or cell(s), or table and selection is simply a collection of "Grid Range" objects. The grid range can be a single row or a range of contiguous rows. It can a single cell or a rectangle of cells (must be contiguous also), and so on and so forth. One advantage is that you can perform set-style operations on it. You can do unions of selections, intersections, "contains" style queries. For example, Selection.AnyRangeContains(rowIndex, colIndex). That's a cheap query because you simply go through your list of ranges (which is generally short, unless you've got a ton of non-contiguous selections), and simply check to see if the cell is contained in the bounds of any of the ranges. Users of the grid like the ability to get the list of selected rows or columns, so we offer that kind of functionality as well, by way of a wrapper method that returns an array of row indices. It does make those type of queries a little slower, but not much. You simply go through the list of ranges and take all of type "row" and add an index for every row in the row range. Anyway, I just thought I'd mention it. I also noticed you're doing the cell renderers on a column basis. 95% of the time, this is all that's needed, but we've had some grids where people have things turned 90 degrees: Say 2 columns of side-by-side data with different types on each row. I don't recall what they have in there, but it's like Low value, Mean value, High value and some other stuff like that where having the data in columns like that, makes sense. We've also had situations where people want to change the cell type based on other contents of the row. Is there any way to override the cell renderer of a particular cell? If not, it might be useful. Our grid is very event-driven. When painting cells, we fire off an event for each cell before we paint it that allows people to override all sorts of things. Colors, renderer, even the values, among a whole host of other things. Anyway, I'm not being critical at all. I'm simply throwing out some ideas... I'll look it over some more. I've had enough time working on this grid that there are a LOT of things I'd do differently if I had it to do over again. Pete _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
