Home » Eclipse Projects » NatTable » Weird issue with FilterRow and Scrollbars
Weird issue with FilterRow and Scrollbars [message #989517] |
Thu, 06 December 2012 15: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 16: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 08:17 |
Dirk Fauth Messages: 2902 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 10: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.
|
|
| |
Re: Weird issue with FilterRow and Scrollbars [message #1405013 is a reply to message #989691] |
Wed, 06 August 2014 11:24 |
István Mészáros Messages: 51 Registered: October 2009 |
Member |
|
|
Hello all,
i also bumped into a similar issue, although i'm using a standard layout manager:
- at start, vertical scroll bar must be visible
- open a filter editor
- set a filter condition that causes all rows to disappear
- this also causes the vertical bar to disappear (the filter editor is still open)
- change the filter condition again, and here comes the surprise..
- the filter values are set to the column on the left of the original column
Since i couldn't get to the source of the problem, my first idea was also to change the scroll bar to always remain visible.
Unfortunately this is difficult ass hell with the current API, so i post here my very-very ugly workaround:
// build nattable as you would normally
...
natTable = new NatTable(this, gridLayer, false);
// here comes the ugly workaround to haven an always-visible vertical scroll bar
final ScrollBarScroller scroller = new ScrollBarScroller(natTable.getVerticalBar()) {
@Override
public void setVisible(boolean b) {
// this does the trick (as it doesn't do anything)
}
};
final VerticalScrollBarHandler vBarListener = new VerticalScrollBarHandler(viewportLayer, scroller);
final Field tableField = ReflectionUtils
.getDeclaredFieldRecursively(VerticalScrollBarHandler.class, "table");
ReflectionUtils.setFieldValue(tableField, vBarListener, natTable);
final Field vBarListenerField = ReflectionUtils
.getDeclaredFieldRecursively(ViewportLayer.class, "vBarListener");
ReflectionUtils.setFieldValue(vBarListenerField, viewportLayer, vBarListener);
natTable.setConfigRegistry(configRegistry);
// etc...
natTable.configure();
ReflectionUtils is a utility class of mine that simplifies reflection related tasks, i assume the method names are verbose enough the see what's happening.
[Updated on: Wed, 06 August 2014 11:36] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Fri Mar 29 10:47:07 GMT 2024
Powered by FUDForum. Page generated in 0.02577 seconds
|