After we switched to remoteswinglibrary-1.1.1 from a fairly old swinglibrary-1.1.3, we faced a new problem with Get Table Cell Value keyword. Our application is extracting table cell values from a fairly large tree table and the implementation is originally done with quite early version of Swing. This added some complexity to the issue.
ProblemOne piece of text we saw in the Get Table Cell Value keyword definition was leading us into right direction:
"Starting from SwingLibrary 1.1.4, value from cell rendered with check box is string true/false."
With remoteswinglibrary-1.1.1 getting cell values from the tree table always led to an exception like this:
16:10:28.392 DEBUG XyzCellRenderer cannot be cast to javax.swing.AbstractButton
at org.robotframework.swing.table.CellValueExtractor.textOf(CellValueExtractor.java:26)
at org.robotframework.swing.table.TableOperator.getCellValue(TableOperator.java:58)
at org.robotframework.swing.keyword.table.TableKeywords.getTableCellValue(TableKeywords.java:122)
The problem actually wasn’t the our TreeTable component as we first thought. We noticed that swinglibrary was assuming that Boolean values are rendered as buttons, while our implementation is intentionally rendering Booleans in text format. Combined with our tree table cell renderer implementations, the swinglibrary was treating all types of table cells as AbstractButton based.
FixOriginal CellValueExtractor code:
public String textOf(int row, int col) {
try {
Component cellRendererComponent = getCellRendererComponent(row, col);
if (isCheckboxRenderer(cellRendererComponent))
return new Boolean(((AbstractButton) cellRendererComponent).isSelected()).toString();
return coerceToWithText(cellRendererComponent).getText();
} catch (AllMethodsNotImplementedException e) {
return wrapElementToWithText(row, col).getText();
}
}
. . .
private boolean isCheckboxRenderer(Component cellRendererComponent) {
TableCellRenderer defaultCheckboxRenderer = ((JTable) jTableOperator.getSource()).getDefaultRenderer(Boolean.class);
return (defaultCheckboxRenderer.getClass().isInstance(cellRendererComponent));
}
In our implementation the renderer component for Booleans is in the same class hierarchy with other renderer classes. When the isCheckboxRenderer() does the isInstance() call, the result is always true. In textOf() the code makes an additional assumption that the renderer is an instance of AbstractButton. This is actually not checked in the isCheckboxRenderer() method.
Changed CellValueExtractor code:
private boolean isButtonBasedRenderer(Component cellRendererComponent) {
TableCellRenderer defaultCheckboxRenderer = ((JTable) jTableOperator.getSource()).getDefaultRenderer(Boolean.class);
return (defaultCheckboxRenderer.getClass().isInstance(cellRendererComponent) &&
cellRendererComponent instanceof AbstractButton);
}
We modified isCheckboxRenderer() method and renamed it to be a bit more descriptive. The purpose there is to make sure the renderer actually is based on AbstractButton by adding the '&& cellRendererComponent instanceof AbstractButton' part. This will make sure the renderer is AbstractButton based before casting it in textOf() method.
This has worked for us and not broken anything so far. The fix is quite minimal to avoid possible ill-effects, trying just to avoid the situation when the renderer was wrongly cast into AbstractButton. More exotic Button based renderer implementations could still cause some kind of problems.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4