Home » Eclipse Projects » NatTable » Weird issue with FilterRow and Scrollbars
Weird issue with FilterRow and Scrollbars [message #989517] |
Thu, 06 December 2012 10:09  |
|
Hello all,
I'm currently working on a NatTable powered application that makes use of filters. The code is pretty much adapter for Dirk's example posted way back in 2011 in the Eclipse magazine. It all works well however I've noticed the following weird behavior on Windows 7 *only*:
There's a table with filters configured. You can set and delete filters all day long. If no rows are available the filters continue to work. However, if rows become available and the vertical scrollbar gets drawn then it's a different matter.
Activating filters once more makign sure that no rows become available will make the vertical scrollbar disappear, which will push the NatTable's content a bit further into the right. And here comes the problem, you can't click on the "delete filter" icon anymore. You can't even click on the header to select the column. It's as if the space that the scrollbar used to occupy is reserved, or as if the NatTable's dimensions were not updated when the scrollbar went away.
Has anyone experienced something similar? Is this a bug perhaps?
Environment
-----------
Eclipse
Version: Juno Service Release 1
Build id: 20120920-0800
org.eclipse.nebula.widgets.nattable.core_0.9.0.201209230003
Windows 7 Ultimate SP1
|
|
| |
| Re: Weird issue with FilterRow and Scrollbars [message #989530 is a reply to message #989525] |
Thu, 06 December 2012 11:21   |
|
Hi Dirk,
1. The customization is related to a LazyLoadingDataLayer we custom built for this project, which sadly makes no use of GlazedLists at all.
2. Yes indeed, we're making use of the percentage sizing feature. Here's a snippet on how we set it up
lazyLoadingDataLayer.setColumnPercentageSizing(true);
for (int i = 0; i < columns.size(); i++) {
lazyLoadingDataLayer.setColumnWidthPercentageByPosition(i, columns.get(i).getWidthPercentage());
}
We also setup the NatTable using the default style + SWT.BORDER. I wonder, is it possible to instruct the table to always draw the Vertical scrollbar? I must confess the issue has me stumped as it cannot be reproduced in either Linux nor Mac (insert witty retort on how Windows sucks big time here 
3. The NatTable is embedded using MigLayout
//main layout
final LC lc = new LC().fill().wrapAfter(2).insets("0");
final AC cc = new AC().size("310", 0).fill(0, 1).gap("0:0").grow(1, 1);
final AC rc = new AC().fill().grow(1).align("center");
final MigLayout basicLayout = new MigLayout(lc, cc, rc);
// table
manager.getNatTable().setLayoutData("w n:400, h 45:200");
wouldn't the column constraint mean that the table grows in the horizontal dimension? However if setColumnPercentageSizing(false) is set then all columns are drawn with the same size and the table's area is not filled.
Thanks!
|
|
|
| Re: Weird issue with FilterRow and Scrollbars [message #989655 is a reply to message #989530] |
Fri, 07 December 2012 03:17   |
Dirk Fauth Messages: 525 Registered: July 2012 |
Senior Member |
|
|
Hi Andres,
Quote:which sadly makes no use of GlazedLists at all
but you are using GlazedLists in the NatTable, aren't you? Otherwise, which FilterRow are you using? Currently it is only usable with GlazedLists (changing this is still on my ToDo list).
Quote:I wonder, is it possible to instruct the table to always draw the Vertical scrollbar?
Currently not as the ViewportLayer takes care if the scrollbars should be shown or not dependent on the content. Maybe this needs to be adjusted, but until now there was no such requirement. 
Quote:The NatTable is embedded using MigLayout
I never used MigLayer before. For me the SWT FormLayout was always good enough. Maybe I need to have a look at this in the future. 
Quote:wouldn't the column constraint mean that the table grows in the horizontal dimension?
I don't understand which column constraint you mean. Compared to a SWT table, the NatTable doesn't grow to fill the whole space. To be more precise, the NatTable as the Canvas on which the table is painted of course grows dependent to the layout. But what is painted to the Canvas (the cells itself) doesn't know about the layout. Of course the ViewportLayer knows about the size of the visible part to determine whether to show scrollbars or not, but that information isn't transfered to the cell rendering itself. This needs to be configured independent of the layout manager you are using.
Hope the informations help in some kind of way.
I will try to modify my example to reproduce your issue.
Greez,
Dirk
|
|
| |
| Re: Weird issue with FilterRow and Scrollbars [message #989685 is a reply to message #989655] |
Fri, 07 December 2012 05:09   |
|
We circumvented the usage of GlazedLists alltogether. Here's for example how our FilterGridLayer setups the columnHeader
protected ILayer createColumnHeaderLayer(BodyLayerStack bodyLayer,
Map<String, String> titleToAttributeNameMap,
IConfigRegistry configRegistry) {
ILayer columnHeaderLayer = super.createColumnHeaderLayer(bodyLayer,
titleToAttributeNameMap, configRegistry);
FilterRowHeaderComposite<I> filterRowHeaderLayer = new FilterRowHeaderComposite<I>(
new IFilterStrategy<I>() {
@Override
public void applyFilter(
Map<Integer, Object> filterObjectByIndex) {
if (filterCallback == null) return;
Map<String, Object> filterValuesPerColumn = new LinkedHashMap<String, Object>();
for (Map.Entry<Integer, Object> entry : filterObjectByIndex
.entrySet()) {
filterValuesPerColumn.put(
getColumnProperty(entry.getKey()),
entry.getValue());
}
// trigger callback only if filter key/values changed from last time
if (!areEqual(previousFilterValuesPerColumn, filterValuesPerColumn)) {
filterCallback.filter(filterValuesPerColumn);
previousFilterValuesPerColumn.clear();
previousFilterValuesPerColumn.putAll(filterValuesPerColumn);
}
}
}, columnHeaderLayer, columnHeaderDataLayer.getDataProvider(),
configRegistry);
return filterRowHeaderLayer;
}
This layer detects when filters change, collects all relevant information and triggers a filterCallback. It also remember the last filter combination in order to avoid triggering the callback with the same search arguments.
It would be great if we could programmatically instruct ViewportLayer to always draw scrollbars.
MigLayout and GlazedLists => best 3rd party libraries to build UIs, You can ask Sascha 
Lastly, what I meant about the constraints is that grow is set on the table, this instructs the composite to let the table grow in both vertical and horizontal space as it becomes available. This does not affect the inner draw space of the table at all (that is, it won't affect column sizes directly unless of course they are setup in a way that their width changes if the table gets resized).
So, our observations indicate that the table itself is not resized when the vertical scrollbar appears then disappears, i.e, the canvas' size is [400, 400] and remains that size. But it looks like inner dimensions in the table itself are not updated when the vertical scrollbar is hidden, as the effect is that the space where the vertical scrollbar used to be is not selectable/clickable.
Hope this information helps.
|
|
| |
Goto Forum:
Current Time: Sat May 25 12:02:38 EDT 2013
Powered by FUDForum. Page generated in 0.01906 seconds
|