| Editing columns within row header [message #997272] |
Fri, 04 January 2013 21:19  |
 Rashmy A
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
Hello,
I'd like to get your advice on a path of implementation to follow for my use case.
Most of the examples in NatTable have a row header with a single column (indicating row number) or there are no row headers at all. For example:
Colm1 Colm2 Colm3
1 v1 v2 v3
2 v11 v12 v13
3 v21 v22 v23
I have a use case where we would like to display multiple columns in the row header and also be able to edit it.
So this is how it was implemented-
Colm1 Colm2 Colm3
Class1 TypeA v1 v2 v3
Class2 TypeB v11 v12 v13
Class3 TypeB v21 v22 v23
Here within the row header we have 2 columns -
one to show class name and,
another for type name
For editing a cell in the row header-
A double-click MouseEvent listener was added to turn the row header cell into an editable field. Since this is on a MouseEvent, we know the exact cell that is being edited. No call to Selection layer is required. Everything good thus far.
Next, there was need to use the F2 key within the row header to get into editable mode-
This means user selects cell in row header (single mouse click or keyboard navigation), then hits F2 key.
The issue here is that I'm using the default SelectionModel provided by NatTable. So when we select a row, it selects all cells in that row. For example, if user clicks on cell containing "TypeB", it selects all cells in that row. After this, if user hits F2 key there is no way for me to find out which cell in the row header the user wanted to edit. Did the user want to edit cell containing class name or type name? This is the issue at hand.
Question:
Is it advisable to have editable columns within the row header? If yes, does it mean we have to develop our own SelectionModel?
The only reason I started using multiple columns in row header is because the row header is frozen when I horizontally scroll the table. Should I stop having multiple columns in row header and have these columns in body layer and then just freeze the columns that should not be scrolled when using the horizontal scroll bar? Is there any other suggestion you would like to provide?
Thanks!
Rashmy
|
|
|
|
|
|
| Re: Editing columns within row header [message #997865 is a reply to message #997452] |
Tue, 08 January 2013 22:36  |
Rashmy A
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
Hi Dirk,
I tried implementing your suggestion but it does not seem to work.
Here are the changes I made:
-Create my own Selection layer bindings
-Override configureRowHeaderMouseClickBindings() and register ViewportSelectCellAction. Could not use SelectCellAction since I have a viewport layer too. In the action, I created my own ViewportSelectCellCommand (similar to ViewportSelectRowCommnd) and in the command handler I made a call to SelectCellCommand.
Now using the example I provided earlier:
Colm1 Colm2 Colm3
Class1 TypeA v1 v2 v3
Class2 TypeB v11 v12 v13
Class3 TypeB v21 v22 v23
Clicking on cell containing "TypeB" selected the following cells:
Class2
TypeB
v11
Colm1
This is because of how the SelectionModel has stored these selections and also how the display mode is computed.
RowHeaderLayer: We are not using the column position at all to check for selection
public String getDisplayModeByPosition(int columnPosition, int rowPosition) {
int selectionLayerRowPosition = LayerUtil.convertRowPosition(this, rowPosition,
selectionLayer);
if (selectionLayer.isRowPositionSelected(selectionLayerRowPosition))
{
return DisplayMode.SELECT;
}
else
{
return super.getDisplayModeByPosition(columnPosition, rowPosition);
}
}
Similarly when we ask for display mode in the column header layer and body layer, we just get it from SelectionModel which seems return true even if the selection was made only in the row header layer.
Does this mean, I need my own SelectionModel?
Am I missing something?
Thanks,
Rashmy
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04063 seconds
] 
Search
Help
Register
Login
Home
