Community
Participate
Working Groups
If you have a SWT.VIRTUAL table selection outside of the visible range will return TableItems that have null data (call to getData returns null) because they are still virtually allocated. So if you had many items in a table and click the first row and then scroll down to the bottom and shift click the last row to select all items. A call to tableViewer.getElementAt(5000) if you had 10000 rows would return null.
do you have a snippet, using SWT only, to show this problem ?
Created attachment 123816 [details] main runner to show bug (follow steps in my comment)
Comment on attachment 123816 [details] main runner to show bug (follow steps in my comment) I'm sorry I think I may have posted this in the wrong area. I didn't see JFace in the component area. This is a problem with a SWT.VIRTUAL table using a deferred content provider... I have attached sample code. If you load the code and click button 1 you will see that the call to tableViewer.getElementAt(..) to a not yet visualized element returns null. Next, click the first table row, then drag the scroll bar down to the bottom element. Hold in your shift key and click the bottom element (ie: select all rows). Now click button 2. Notice that the selection size that the viewer returns is only a fraction of the 20,000 populated models. This is basically because of the virtual elements return null when their getData method is called. You don't seem to have API access to 'hack' the background content provider to refresh these virtual elements, so there seems to be no work around as I can see with out overriding the jface code. I have attached a screenshot and the bug recreation.
Created attachment 123818 [details] sample screenshot of bug recreation program same screenshot of bug recreation code.
Reassigning to UI for now. Please send it back if it turns to be SWT.
There are several problems with the code in the viewers.deferred package. I am tempted to just mark it deprecated because we don't have the resources to fix the issues, and don't know of any clients that use it successfully. Can you reproduce the problem without using viewers.deferred, i.e. with only TableViewer and either an IStructuredContentProvider or ILazyContentProvider?
Do you know of a way to populate the table in a background thread. I don't care so much about sorting in a background thread. My business requirements are to be able to cancel the population of the table at any time and populate it with what has been retrieved so far... You may want to see if the contact at http://publicsvn.bestsolution.at/WebSVN/listing.php?repname=svnpublic&path=%2F&sc=0 may have some information. I started a dialog with him and it seems that he was planning to fix .deferred . Unfortunately it doesn't look like I have any time at the moment to help out.
(In reply to comment #7) > You may want to see if the contact at > http://publicsvn.bestsolution.at/WebSVN/listing.php?repname=svnpublic&path=%2F&sc=0 > may have some information. I started a dialog with him and it seems that he > was planning to fix .deferred . Tom?
Sorry, wrong field ;)
Well async is on the list of issues of the E4-Viewers rewrite I've started but there's no concrete plan currently.
Hitesh is now responsible for watching bugs in the [Viewers] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
