| Possible Bug in CompositeFreezeLayer [message #1786448] |
Thu, 03 May 2018 09:23  |
Eclipse User |
|
|
|
Good day,
Our testers are using UI testing tools which use some of the properties of the NatTable. We have some tables that use the CompositeFreezeLayer to freeze some columns.
When there are froze columns, the value returned by getPreferredColumnCount is different than if there are no frozen columns and returns a value that is higher than the actual number of columns in the table.
For example, a table may have 9 columns. When not frozen, the value returned by getPreferredColumnCount is 9. If we freeze 3 columns, the value returned by getPreferredColumnCount is 12.
Based on what I can tell, the function from CompositeLayer is written as:
@Override
public int getPreferredColumnCount() {
int preferredColumnCount = 0;
for (int layoutX = 0; layoutX < this.layoutXCount; layoutX++) {
preferredColumnCount += this.childLayerLayout[layoutX][0].getPreferredColumnCount();
}
return preferredColumnCount;
}
Which goes through the child layers of the CompositeFreezeLayer and counts the frozen columns twice in that process.
The tentative fix I have is to have the CompositeFreezeLayer implement the function as follows:
@Override
public int getPreferredColumnCount() {
return getChildLayerByRegionName("NONFROZEN_REGION").getPreferredColumnCount(); //$NON-NLS-1$
}
But before I move forward with this I just wanted to check with the people her to see if there is a reason for the getPreferredColumnCount to count the frozen columns twice.
Please note that the same issue is seen with getPreferredRowCount and would require a similar fix.
Thanks for your help
|
|
|
| Re: Possible Bug in CompositeFreezeLayer [message #1786568 is a reply to message #1786448] |
Mon, 07 May 2018 08:41  |
| Eclipse User |
|
|
|
Well, I am not sure what to say about that. Actually the methods you refer to are not used anywhere in NatTable. They just exist. And they are not even documented, so I really don't know about the intended semantics. They were added before I stepped into the project.
That said I wonder why anybody is testing things that are not used anywhere, but well, that is what testers do right? I can only assume that the idea was to return the unmodified number of rows and columns, regardless the transformation added by a layer. For example if the ViewportLayer only shows 5 of 10 columns, then getColumnCount() will return 5 while getPreferredColumnCount() still returns 10.
We could now have a lot of discussion on the solution. Actually I think your solution is wrong and the CompositeLayer implementation is correct. If there is an issue I would search in the ViewportLayer. It truncates the view on the underlying layer but it still says the preferred column count is the same as the underlying one. But the semantic of that method is to return the column count without transformations. So who is right? If we would connect the FreezeLayer and the ViewportLayer without any additional transformation side to side, than we would have 12 columns in your example. The FreezeLayer has 3 columns as that is his purpose, the ViewportLayer without any transformation would show 9 columns, as the would neither truncate the columns nor would he return only a viewport but everything.
From my point of view, without a definition of the purpose of this API and no usage of that API, I wonder if such a discussion really makes sense.
If you think it is worth the effort, well create a ticket and provide a patch I can check and integrate.
|
|
|
Powered by
FUDForum. Page generated in 0.04604 seconds
Home