Migrate ILayerCell from underlying layer to top-level [message #1258189] |
Thu, 27 February 2014 06:24 |
|
Hey!
I'm trying to fire an EditCellCommand using the ILayerCell i can get by calling SelectionLayer.getCellByPosition(selLayer.getSelectionAnchor()....). The cell is bound to the selection layer, and when i fire the edit command, the editor will open up in the wrong place We're using a custom cell editor implementation, so maybe there is something wrong too. When i manually add the offsets for column header and row header (+1 on positions), then the editor opens up in the correct cell. However +1 is not sooo future proof
I saw that LayerUtil.convert* would do what i need but require a IUniqueIndexLayer, which the top level grid layer is not...
the only idea i currently have is adding the column header row count to the row position and the row header column count to the column position. but this is also not bullet proof in case there is more transformation on top of the selection layer, or for some reason, the cell is not from the selection layer but an underlying one.
Any Ideas? Thanks!
|
|
|
|
|
|
|
Re: Migrate ILayerCell from underlying layer to top-level [message #1258285 is a reply to message #1258271] |
Thu, 27 February 2014 08:32 |
|
We have a whole bunch of "old" editor framework that we are wrapping using a custom ICellEditor implementation. Basically it just creates a composite with some arbitrary editor controls on it. Bounds of the editor are calculated using the method i posted above. Now there is (use case one) a UI test framework which tries to programmatically open an editor for a cell. The test framework only has data layer indexes in hand, so what we do there is this:
@Override
public BaseControl getAndCreateTableCellEditor(int rowIndex, int columnIndex) {
DataLayer dataLayer = getLayer().getBodyLayer().getDataLayer();
ILayerCell cell = dataLayer.getCellByPosition(columnIndex, rowIndex);
if (cell == null) {
throw new RuntimeException("No cell available at row=" + rowIndex + " column="
+ columnIndex);
}
// skip re-sizing during programmatic editing
NatTableCellEditor cellEditor = (NatTableCellEditor) natTable.getConfigRegistry()
.getConfigAttribute(EditConfigAttributes.CELL_EDITOR, DisplayMode.EDIT);
try {
cellEditor.setAutoResizeCell(false);
natTable.doCommand(new EditCellCommand(natTable, natTable.getConfigRegistry(), cell));
} finally {
cellEditor.setAutoResizeCell(true);
}
// check if we could create an editor
NatTableCellEditor activeEditor = (NatTableCellEditor) natTable.getActiveEditor();
if (activeEditor == null) {
throw new CellNotEditableException(rowIndex, columnIndex);
}
return editor;
}
Firing this EditCellCommand with the cell from the data layer will somehow skip the offsetting required to take header layers into account (row and column headers), thus the editor will be opened a little too high, and a little too far on the left. I confirmed that the coordinates that are passed to calculacteBounds (by nattable itself) are off by that amount.
BTW, i solved the viewport issue, by always converting to selection layer positions, so only the cell/editor offset issue remains.
|
|
|
Re: Migrate ILayerCell from underlying layer to top-level [message #1258310 is a reply to message #1258285] |
Thu, 27 February 2014 08:57 |
Dirk Fauth Messages: 2902 Registered: July 2012 |
Senior Member |
|
|
The cell coordinates in NatTable are all using offsets. So if you are getting cell 1,1 of the body data layer, it will be 2,2 in a grid, because there is one row in the column header and one column in the row header. Using the method above, your code will never work in a grid composition.
Maybe this kind of code helps:
natTable.doCommand(new SelectCellCommand(getLayer().getBodyLayer().getSelectionLayer(), columnIndex, rowIndex, false, false));
natTable.doCommand(new EditSelectionCommand(natTable, natTable.getConfigRegistry()));
|
|
|
|
|
Re: Migrate ILayerCell from underlying layer to top-level [message #1258367 is a reply to message #1258344] |
Thu, 27 February 2014 10:03 |
|
Oh, no, actually we're doing UI tests to verify the logical functionality (and completeness) of the application. The table is "only" another widget that needs to be driven by the tests. This is done programmatically by running a small server inside the application that can control widgets. This server is sent commands like where to edit or fill out data, and then executes this more or less like the user would. (we're not using SWTBot for that )
[Updated on: Thu, 27 February 2014 10:03] Report message to a moderator
|
|
|
Powered by
FUDForum. Page generated in 2.40452 seconds