Adds a trivial extension to the possible cell editors for a TableView to support tri-state checkboxes.
This patch implements the feature. Tested in our application where we have a TriState column in several of our TableViews.
I like the concept, but I wonder if TableViewBooleanCellRenderer and TableViewTriStateCellRenderer should be separate (booleans technically don't support three values).
That was the way I originally implemented it, but there was so much code overlap that I tried essentially combining them. But, it is easy enough to go back the other way. What do you think of using the "load" method on the Checkbox to set the value in the "render()" method? It seems like it does everything that is needed....
The other thing I thought about was only changing the BooleanRenderer to make the checkbox protected, and then only override the constructor and "render" methods in the TriState case. That way there would be no tri-state code in the boolean one, and there would still be less code duplication....
Using load() seems reasonable. It is also used by the row editor.
I don't see a problem sharing code between the boolean and the tri-state versions (or consolidating them), but maybe it would be better to call it TableViewCheckboxCellRenderer if that is the case.
Do you mean making a base class TableViewCheckboxCellRenderer (that is just a rename of what I have for the Boolean one) and two subclasses: TableViewBooleanCellRenderer which just has a constructor that calls "super()", and another subclass TableViewTriStateCellRenderer that just has a constructor with the "super()" and the "setTriState()" call?
That way it wouldn't break any existing code, and make maximum reuse....
I think ideally we could just get away with the one TableViewCheckboxCellRenderer class, but in order to maintain backward compatibility doing what you describe makes sense.
Okay, this implements this hierarchy: base class with two subclasses.
Tested with my application and all is well.
Looks good to me. You have commit rights now, right? Feel free to check it in.
Thanks. I will tonight.
if you commit (of course in the trunk, currently), remember to assign to yourself, and change the fix version as 2.0.1, and not 2.1 ...
Committed revision 1138493.