Eclipse Community Forums: NatTable » Question about GroupBy

Home » Eclipse Projects » NatTable » Question about GroupBy

Question about GroupBy [message #1717705]

Wed, 16 December 2015 02:33

Eclipse User

Hello,

recently i reconfigured my NatTable-Wrapper* (i'm able to switch the configuration/versions in the application for testing)

so in my old version i did not have GroupBy.
when i change the input of the table i simply call

observableList.clear();
observableList.addAll(newList);

if i now switch to the new version with GroupBy i have to call this

observableList.clear();
observableList.addAll(newList);
		Display.getDefault().asyncExec(new Runnable() {

			@Override
			public void run() {
				natTable.refresh();
			}
		});

if i do not do the refresh the table shows no rows (but it still shows me the count of rows in the corner, so the data is available)

[EDIT] after adding the refresh() i get various exceptions. one of them is for example: ('m only changing the input, no action is taken in changing sort order or similar.)
eg:

 java.lang.ArrayIndexOutOfBoundsException: 2
	at ca.odell.glazedlists.SortedList.setComparator(SortedList.java:475)
	at ca.odell.glazedlists.gui.AbstractTableComparatorChooser.rebuildComparator(AbstractTableComparatorChooser.java:154)
	at ca.odell.glazedlists.gui.AbstractTableComparatorChooser$SortingStateListener.propertyChange(AbstractTableComparatorChooser.java:140)
	at java.beans.PropertyChangeSupport.fire(Unknown Source)
	at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
	at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
	at ca.odell.glazedlists.impl.gui.SortingState.fireSortingChanged(SortingState.java:67)
	at ca.odell.glazedlists.gui.AbstractTableComparatorChooser.fromString(AbstractTableComparatorChooser.java:313)
	at org.eclipse.nebula.widgets.nattable.extension.glazedlists.GlazedListsSortModel.handleLayerEvent(GlazedListsSortModel.java:128)
	at org.eclipse.nebula.widgets.nattable.layer.AbstractLayer.fireLayerEvent(AbstractLayer.java:279)
	at org.eclipse.nebula.widgets.nattable.command.StructuralRefreshCommandHandler.doCommand(StructuralRefreshCommandHandler.java:41)
	at org.eclipse.nebula.widgets.nattable.command.StructuralRefreshCommandHandler.doCommand(StructuralRefreshCommandHandler.java:1)
	at org.eclipse.nebula.widgets.nattable.layer.AbstractLayer.doCommand(AbstractLayer.java:178)
	at org.eclipse.nebula.widgets.nattable.layer.DataLayer.doCommand(DataLayer.java:496)
	at org.eclipse.nebula.widgets.nattable.grid.layer.DimensionallyDependentLayer.doCommand(DimensionallyDependentLayer.java:163)
	at org.eclipse.nebula.widgets.nattable.layer.AbstractLayerTransform.doCommand(AbstractLayerTransform.java:107)
	at org.eclipse.nebula.widgets.nattable.layer.AbstractLayerTransform.doCommand(AbstractLayerTransform.java:107)
	at org.eclipse.nebula.widgets.nattable.layer.CompositeLayer.doCommandOnChildLayers(CompositeLayer.java:142)
	at org.eclipse.nebula.widgets.nattable.layer.CompositeLayer.doCommand(CompositeLayer.java:134)
	at org.eclipse.nebula.widgets.nattable.filterrow.FilterRowHeaderComposite.doCommand(FilterRowHeaderComposite.java:90)
	at org.eclipse.nebula.widgets.nattable.layer.AbstractLayerTransform.doCommand(AbstractLayerTransform.java:107)
	at org.eclipse.nebula.widgets.nattable.grid.layer.GridLayer.doCommandOnChildLayer(GridLayer.java:113)
	at org.eclipse.nebula.widgets.nattable.grid.layer.GridLayer.doCommandOnChildLayers(GridLayer.java:101)
	at org.eclipse.nebula.widgets.nattable.layer.CompositeLayer.doCommand(CompositeLayer.java:134)
	at org.eclipse.nebula.widgets.nattable.grid.layer.GridLayer.doCommand(GridLayer.java:187)
	at org.eclipse.nebula.widgets.nattable.grid.layer.DimensionallyDependentLayer.doCommand(DimensionallyDependentLayer.java:158)
	at org.eclipse.nebula.widgets.nattable.layer.CompositeLayer.doCommandOnChildLayers(CompositeLayer.java:142)
	at org.eclipse.nebula.widgets.nattable.layer.CompositeLayer.doCommand(CompositeLayer.java:134)
	at org.eclipse.nebula.widgets.nattable.NatTable.doCommand(NatTable.java:739)
	at org.eclipse.nebula.widgets.nattable.NatTable.refresh(NatTable.java:559)

What i noticed while looking at the properties:
You added a prefix Grid. to the properties key.
this prefix is not available on GROUP_BY_REGION
(an example is on the end of this post)

is this done on purpose?

*i call it wrapper because i wrap my whole configuration, labels, styling etc into it.

#config for natTable
#Wed Dec 16 08:11:17 CET 2015
Grid.BODY.FROZEN_COLUMN_REGION.hiddenColumnIndexes=1,2,3,4,5,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,
Grid.BODY.FROZEN_ROW_REGION.columnWidth.percentageSizing=false
Grid.BODY.FROZEN_ROW_REGION.columnIndexOrder=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,
Grid.BODY.FROZEN_ROW_REGION.columnWidth.resizableByDefault=true
Grid.COLUMN_HEADER.FILTER_ROW.columnWidth.percentageSizing=false
Grid.BODY.NONFROZEN_REGION.columnWidth.percentageSizing=false
Grid.BODY.FROZEN_COLUMN_REGION.columnWidth.defaultSize=100
Grid.BODY.NONFROZEN_REGION.columnIndexOrder=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,
Grid.ROW_HEADER.columnWidth.percentageSizing=false
Grid.BODY.FROZEN_REGION.columnIndexOrder=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,
Grid.COLUMN_HEADER.columnHeader.columnWidth.percentageSizing=false
Grid.COLUMN_HEADER.FILTER_ROW.columnWidth.resizableByDefault=true
Grid.CORNER.rowHeight.percentageSizing=false
Grid.CORNER.columnWidth.resizableByDefault=true
Grid.BODY.FROZEN_ROW_REGION.hiddenColumnIndexes=1,2,3,4,5,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,
GROUP_BY_REGION.rowHeight.resizableByDefault=true
GROUP_BY_REGION.rowHeight.percentageSizing=false
Grid.BODY.FROZEN_ROW_REGION.columnWidth.defaultSize=100
Grid.CORNER.rowHeight.defaultSize=20
Grid.BODY.FROZEN_COLUMN_REGION.rowHeight.percentageSizing=false
Grid.BODY.freezeTopLeftPosition=-1,-1
Grid.COLUMN_HEADER.FILTER_ROW.rowHeight.defaultSize=20
Grid.CORNER.columnWidth.defaultSize=100
Grid.BODY.FROZEN_REGION.columnWidth.percentageSizing=false
Grid.CORNER.rowHeight.resizableByDefault=true
Grid.BODY.FROZEN_COLUMN_REGION.columnWidth.resizableByDefault=true
Grid.BODY.NONFROZEN_REGION.rowHeight.defaultSize=20
Grid.BODY.FROZEN_REGION.rowHeight.percentageSizing=false
Grid.BODY.FROZEN_ROW_REGION.rowHeight.defaultSize=20
Grid.BODY.FROZEN_COLUMN_REGION.rowHeight.resizableByDefault=true
Grid.BODY.NONFROZEN_REGION.hiddenColumnIndexes=1,2,3,4,5,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,
Grid.BODY.NONFROZEN_REGION.columnWidth.resizableByDefault=true
Grid.BODY.FROZEN_COLUMN_REGION.columnIndexOrder=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,
Grid.BODY.FROZEN_ROW_REGION.rowHeight.resizableByDefault=true
Grid.COLUMN_HEADER.FILTER_ROW.rowHeight.resizableByDefault=true
Grid.BODY.NONFROZEN_REGION.rowHeight.resizableByDefault=true
Grid.ROW_HEADER.rowHeight.resizableByDefault=true
Grid.COLUMN_HEADER.columnHeader.columnWidth.defaultSize=100
Grid.ROW_HEADER.columnWidth.defaultSize=50
GROUP_BY_REGION.columnWidth.resizableByDefault=true
Grid.BODY.FROZEN_REGION.hiddenColumnIndexes=1,2,3,4,5,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,
GROUP_BY_REGION.columnWidth.defaultSize=100
Grid.COLUMN_HEADER.columnHeader.rowHeight.resizableByDefault=true
Grid.COLUMN_HEADER.columnHeader.columnGroups=
Grid.BODY.FROZEN_COLUMN_REGION.rowHeight.defaultSize=20
Grid.ROW_HEADER.rowHeight.defaultSize=40
GROUP_BY_REGION.columnWidth.percentageSizing=false
Grid.BODY.FROZEN_REGION.rowHeight.defaultSize=20
Grid.COLUMN_HEADER.columnHeader.columnWidth.resizableByDefault=true
Grid.ROW_HEADER.columnWidth.defaultSizes=0\:60,
GROUP_BY_REGION.groupByColumnIndexes=7,
Grid.COLUMN_HEADER.columnHeader.rowHeight.defaultSize=20
Grid.COLUMN_HEADER.FILTER_ROW.columnWidth.defaultSize=100
Grid.ROW_HEADER.rowHeight.percentageSizing=false
Grid.BODY.NONFROZEN_REGION.columnWidth.defaultSize=100
Grid.COLUMN_HEADER.FILTER_ROW.rowHeight.percentageSizing=false
Grid.CORNER.columnWidth.percentageSizing=false
Grid.BODY.FROZEN_REGION.columnWidth.defaultSize=100
GROUP_BY_REGION.rowHeight.sizes=0\:30,
Grid.BODY.freezeBottomRightPosition=-1,-1
GROUP_BY_REGION.rowHeight.defaultSize=20
Grid.BODY.FROZEN_REGION.rowHeight.resizableByDefault=true
Grid.COLUMN_HEADER.columnHeader.rowHeight.percentageSizing=false
Grid.BODY.FROZEN_ROW_REGION.rowHeight.percentageSizing=false
Grid.BODY.NONFROZEN_REGION.rowHeight.percentageSizing=false
Grid.BODY.FROZEN_REGION.columnWidth.resizableByDefault=true
Grid.BODY.FROZEN_COLUMN_REGION.columnWidth.percentageSizing=false
Grid.ROW_HEADER.columnWidth.resizableByDefault=true

[Updated on: Wed, 16 December 2015 03:09] by Moderator

Re: Strange behaviour iff using GroupBy [message #1717709 is a reply to message #1717705]

Wed, 16 December 2015 03:09

Eclipse User

I suppose you are using a CompositeLayer to achieve a composition with the GroupByHeader. Therefore Grid is the prefix that is added because it is the bottom part of the composition that contains your grid, while the GROUP_BY_REGION is the top part. IIRC this is done by the CompositeLayer using the region name.

Using your approach has the effect that you would even re-apply the groupBy state in case you have a grouped state on switching the content.

IIRC the issue you describe has something to do with caching in the GroupByModel because the TreeList is caching some tree information (based on the GroupBy information). These need to be updated on switching the content. With using the loadState() you are triggering an update of the observable in GroupByModel. So basically you should be able to achieve a simple update by operating on the GroupByModel to trigger an update.

Re: Strange behaviour iff using GroupBy [message #1717711 is a reply to message #1717709]

Wed, 16 December 2015 03:38

Eclipse User

thanks for the fast reply.
i understand, but how can i refresh/update the groupByModel? (by saving and loading its states?
as i do not want to change anything on the groupModel unless the user interacts with it. (i'm just programmatically updating the input for the table...)

you are right i'm using a CompositeLayer, which is causing problems in other parts of my code (too)
how do i get the BodyLayer from natTable when using a CompositeLayer?
my current code is using the GridLayer:

RowPositionCoordinate coord = LayerCommandUtil
				.convertRowPositionToTargetContext(new RowPositionCoordinate(
						natTable, getGridRowPosition()), ((GridLayer) natTable.getLayer()).getBodyLayer());

which now throws an exception due casting CompositeLayer to GridLayer

Re: Strange behaviour iff using GroupBy [message #1717718 is a reply to message #1717711]

Wed, 16 December 2015 05:07

Eclipse User

I suppose you have a GlazedListsEventLayer in place?

And how do you update the content of your NatTable?

The following is the workaround for the TreeList update in GroupByDataLayer. Maybe that helps.

GroupByDataLayer.this.eventList.getReadWriteLock().writeLock().lock();
                try {
                    EventList<T> temp = GlazedLists.eventList(GroupByDataLayer.this.eventList);
                    GlazedLists.replaceAll(eventList, temp, true);
                } finally {
                    GroupByDataLayer.this.eventList.getReadWriteLock().writeLock().unlock();
                }

You could also create a ticket to add an upate method to GroupByModel which would allow to notify the observers without changing the model directly.

Re: Strange behaviour iff using GroupBy [message #1717719 is a reply to message #1717718]

Wed, 16 December 2015 05:09

Eclipse User

Oh, and regarding your second question, well it is never a good idea to get the underlying layer of a NatTable and cast it by hand. Basically you can not get the body layer directly via NatTable, because the NatTable has itself no information about the layer stack. And IMHO it is an anti-pattern to try it your way.

If you have created a wrapper, than I suggest to add a method in that wrapper that allows to request the body layer directly. You need to have it created somewhere, so you should be able to keep that reference and return it somewhere. Anything else is error prone.

Re: Strange behaviour iff using GroupBy [message #1717734 is a reply to message #1717719]

Wed, 16 December 2015 06:48

Eclipse User

1) there is no need to 'add' this method, as it is already available, but its protected i'm calling it now, using reflection.

Method m;
m = GroupByDataLayer.class.getDeclaredMethod("updateTree", null);
m.setAccessible(true);
m.invoke(groupByDataLayer, (Object[]) null);

this seems to solve the problem.

2) the code about the RowPositionCoordinate was written by fipro and is an AbstractMouseSelectionAction

so i'm goging to modify the code to pass my wrapper (which has all needed data available!).

Re: Strange behaviour iff using GroupBy [message #1717738 is a reply to message #1717734]

Wed, 16 December 2015 07:20

Eclipse User

So making the method public would help? Please create a ticket for this. Wink

Regarding the second one, I am fipro. And I can only assume I did this as an example in the early days. Where did you find it?

Re: Strange behaviour iff using GroupBy [message #1717777 is a reply to message #1717738]

Wed, 16 December 2015 11:16

Eclipse User

Just noticed that calling updateTree will loose the sorting state. So probably it would be better to have a refresh on the model which triggers a correct update keeping the sorted state intact via observable update.

Re: Strange behaviour iff using GroupBy [message #1717778 is a reply to message #1717777]

Wed, 16 December 2015 11:25

Eclipse User

1) the code came directly from you (long time back, when nattable was not in eclipse)
2) which model do you mean? the refresh on the model will be done by nattable.refresh()?
sorry Smile

Re: Strange behaviour iff using GroupBy [message #1717779 is a reply to message #1717778]

Wed, 16 December 2015 11:28

Eclipse User

As I said, fipro is me so for sure I gave that code as an example. Smile

You can do it, but as I know now, you shouldn't. Wink

GroupByModel ... the better solution would be to have a refresh method there, which then triggers the update of the tree structure via observable. Calling GroupByDataLayer#updateTree() will cause issues with the sorted state as the sorting will not be applied correctly.

Re: Strange behaviour iff using GroupBy [message #1717892 is a reply to message #1717779]

Thu, 17 December 2015 09:12

Eclipse User

so, as GroupByModel does not have such a method i just file a request and use GroupByDataLayer#updateTree() in the meantime (though sorting stuff gets lost)?

Re: Strange behaviour iff using GroupBy [message #1717900 is a reply to message #1717892]

Thu, 17 December 2015 10:34

Eclipse User

I would say so yes ... but please file the request so I don't forget about that Wink

Re: Strange behaviour iff using GroupBy [message #1717901 is a reply to message #1717900]

Thu, 17 December 2015 10:43

Eclipse User

'bug' is added as 484589

Thanks for your help!

[Updated on: Thu, 17 December 2015 10:44] by Moderator

Re: Strange behaviour iff using GroupBy [message #1718191 is a reply to message #1717901]

Mon, 21 December 2015 02:51

Eclipse User

more information.
calling the updateTree manually (via reflection)
causes this exception:

java.lang.IndexOutOfBoundsException: Cannot get at 37 on list of size 37
	at ca.odell.glazedlists.TransformedList.get(TransformedList.java:105)
	at ca.odell.glazedlists.TransformedList.get(TransformedList.java:106)
	at ca.odell.glazedlists.TransformedList.get(TransformedList.java:106)
	at ca.odell.glazedlists.TransformedList.get(TransformedList.java:106)
	at ca.odell.glazedlists.impl.SimpleIterator.next(SimpleIterator.java:51)
	at ca.odell.glazedlists.BasicEventList.addAll(BasicEventList.java:161)
	at ca.odell.glazedlists.BasicEventList.addAll(BasicEventList.java:149)
	at ca.odell.glazedlists.GlazedLists.eventList(GlazedLists.java:386)
	at org.eclipse.nebula.widgets.nattable.extension.glazedlists.groupBy.GroupByDataLayer$1.run(GroupByDataLayer.java:285)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.nebula.widgets.nattable.extension.glazedlists.groupBy.GroupByDataLayer.updateTree(GroupByDataLayer.java:272)
	... 44 more

java.lang.IndexOutOfBoundsException: Cannot get at 0 on list of size 0
	at ca.odell.glazedlists.TransformedList.get(TransformedList.java:105)
	at ca.odell.glazedlists.TransformedList.get(TransformedList.java:106)
	at ca.odell.glazedlists.TransformedList.get(TransformedList.java:106)
	at ca.odell.glazedlists.TransformedList.get(TransformedList.java:106)
	at ca.odell.glazedlists.impl.SimpleIterator.next(SimpleIterator.java:51)
	at ca.odell.glazedlists.AbstractEventList.clear(AbstractEventList.java:423)
	at ca.odell.glazedlists.TransformedList.clear(TransformedList.java:96)
	at org.eclipse.nebula.widgets.nattable.extension.glazedlists.groupBy.GroupByDataLayer$1.run(GroupByDataLayer.java:286)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.nebula.widgets.nattable.extension.glazedlists.groupBy.GroupByDataLayer.updateTree(GroupByDataLayer.java:272)
	... 44 more

etc

Re: Strange behaviour iff using GroupBy [message #1718197 is a reply to message #1718191]

Mon, 21 December 2015 03:46

Eclipse User

Try to disable the event processing in the GlazedListsEventLayer.

It might also be related to the fact (I learned recently) that it is better to use GlazedLists#replaceAll() instead of a manual clear() + addAll()

But honestly speaking I'm not sure anymore if you need to perform the update manually yourself. Have a look at _809_GroupBySummarySummaryRowExample (NatTable Examples -> Tutorial Examples -> Integration -> GroupBySummarySummaryRowExample). There you can change the content in grouped and sorted state and everything updates correctly. The code for this is (I already replaced the clear() + addAll() locally with replaceAll() )

                bodyLayerStack.getSortedList().getReadWriteLock().writeLock().lock();
                try {
                    // deactivate
                    bodyLayerStack.getGlazedListsEventLayer().deactivate();
                    GlazedLists.replaceAll(
                            bodyLayerStack.getSortedList(),
                            PersonService.getExtendedPersonsWithAddress(10000), true);
                } finally {
                    bodyLayerStack.getSortedList().getReadWriteLock().writeLock().unlock();
                    // activate
                    bodyLayerStack.getGlazedListsEventLayer().activate();
                }

There is no need to update the tree manually. Looking at your initial post, are you updating the list via your observable list or via the GlazedLists instance? Maybe that is the issue because updating the observable list won't trigger update events in the GlazedLists and therefore the internal listeners and mechanisms are not executed.

Re: Strange behaviour iff using GroupBy [message #1718224 is a reply to message #1718197]

Mon, 21 December 2015 07:47

Eclipse User

this introduced a new 'problem'
none of my objects/classes is comparable, therefore it should have failed with ALL my classes.

funny part is, it did not! it succeeded with one of my classes. actually i do not have a clue why, as the exception raised by all classes is:

java.lang.ClassCastException: lumo.core.biooffice.impl.ContactImpl cannot be cast to java.lang.Comparable

but when running it the cast worked fine (for the Contact) and failed on all others, which implement the same Parent class.

so finally i had to add a comparator for my parent class and pass it to the constructor of the sortedList

sortedList = new SortedList<E>(observableList,	<NewComparatorHere>);

with my first quick tests, the problem seems fixed! iff i do find any sideeffects or problems with it i'll post here again.

once again, thanks for your rapid and excellent help!

[Updated on: Mon, 21 December 2015 07:47] by Moderator

Re: Strange behaviour iff using GroupBy [message #1718234 is a reply to message #1718224]

Mon, 21 December 2015 08:38

Eclipse User

I'm not sure if you are creating the SortedList in a way that it can support interactive sorting.

If you create the SortedList using a Comparator, this will specify the order the list is sorted. If you are creating it without a Comparator parameter, it will use the GlazedLists.comparableComparator(), which will then raise the exception as you see. If you want to support sorting using the mechanisms in NatTable, you should create the SortedList with null as Comparator parameter

sortedList = new SortedList<E>(observableList,	null);

This way there is no initial comparator applied and initially you have an unsorted state. The comparators are then applied dynamically if a user sorts interactively.

Re: Strange behaviour iff using GroupBy [message #1718235 is a reply to message #1718234]

Mon, 21 December 2015 08:58

Eclipse User

i tried those three different setups:
1) sortedList = new SortedList<E>(observableList, <NewComparatorHere>);
2) sortedList = new SortedList<E>(observableList, null);
3) sortedList = new SortedList<E>(observableList);

actually i expected the results from 2 and 3 to be equal, but they arent!

1) gives me a let's call it 'presorted' result - so the results get sorted by the Comparator. but i am still able to sort on any columns i want! (interactive)

2) gives me the same behaviour as 1) but misses the 'presorting'. as i do not need 'presorting' i'll choose this option in my code. i did not think that passing null makes a difference to the code at all...

3) leaves me with the casting exception exceptions

[Updated on: Mon, 21 December 2015 08:58] by Moderator

Re: Strange behaviour iff using GroupBy [message #1718242 is a reply to message #1718235]

Mon, 21 December 2015 09:16

Eclipse User

Quote:

Read The Source Luke!

The third statement is not the same as the second as I already mentioned in my above post. The third statement applies the GlazedLists.comparableComparator() which leads to the exception you are seeing.

Regarding the pre-sorted state, well then it allows a pre-sort but still supports the interactive sorting. But I typically use the unsorted variant. Smile

Re: Strange behaviour iff using GroupBy [message #1719007 is a reply to message #1718242]

Mon, 04 January 2016 07:20

Eclipse User

i noticed a 'new' problem introduced with the change from

	sortedList.clear();
	sortedList.addAll(list);

	GlazedLists.replaceAll(sortedList, list, true);

most of the items are displayed twice! When i change the code back to the original two-liner its working fine!
seems the replaceAll fucks something up.

NOTE: i do have a lot of generics in my code and the strange part is, that this only happens with ONE of my classes, all others are working fine. but i can't see a difference from this class to the others. ALL of em extend a class GUID, which determines if the objects/rows are equal.

any ideas what could cause this?
NOTE: passing a comparator did not resolve the issue. (also not the sorted version))

Re: Strange behaviour iff using GroupBy [message #1719011 is a reply to message #1719007]

Mon, 04 January 2016 07:46

Eclipse User

I also noticed that GlazedLists.replaceAll() is less performant than clear() - addAll(). So I didn't changed the code in NatTable and kept the clear() - addAll() code.

Previous Topic:	display long texts in cell
Next Topic:	Auto resize of the coulmn when filter is applied

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Jun 13 18:16:59 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter