Community
Participate
Working Groups
There exists no support in the TableViewer for the clear operation in Table. If the table doesn't use SWT.VIRTUAL, this could (maybe) be worked around by calling remove-insert .. However, when using the virtual option, TableViewer's remove does not update the VirtualManager which can cause anything from the wrong object being shown (removing chances indeces) to null error being thrown. Using clear directly on the Table will of course cause a null pointer error since item.cached is reset, next time the table needs to display the item VirtualManager fails to locate the item in its hash. Marcel
Tod, someone from SWT who understands both SWT and JFace should review the design of the JFace virtual table viewer sometime soon before 3.1. How about me and Vikki?
That would be a good idea Steve. The main issue we are going to have is people who play directly with the Table API like this example here. We have to decide if we want to have some sort of callback mechanism in place or tell them just to use what is supplied in TableViewer. Marcel you can do the same thing by calling refresh on the viewer and updating your content provider without this issue but Steve and Vikki should look at my implementation so that they can see what the issues are.
Refresh would get the new data displayed (assuming clear isn't called), but this solution doesn't apply to my needs. The fact that an item is kept for each of the table's lines is already a problem, clearing the data might slightly improve that ... My problem is deeper than that. I have a HUGE amount of data to display, could be millions of lines. It is impractical to even create it all even ignoring the memory explosion problem. The idea is to use a virtual table, a table that asks for an item whenever it needs it. The Table as is could probably be used this way by clearing data that's not displayed at the moment (could keep a cache of a certain size for efficiency if user does PgUp-PgDown). The TableViewer assumes too many things about the data especially small data size. The TableViewer should act pretty much like Swing's JTable with model & renderer. Unless the user specifies he wants the data to be cached, no caching should be done. Caching items increases the memory utilization needlessly, the user can control better if to re-generate data if needed of cache it. I've mentioned before, as well as others, that the contents provider model should have a getValueAt(row, col) or at least a getUserItem(row). The VirtualManager (from what I'm understood from its code) only defers the creation of TableItem. The defence of the current TableViewer design has been (correct me if I'm wrong) that if you want to support filtering/sorting this is a must. The contents modal should be responsible for these. It should be able to decide if filtering/sorting is supported and how will this be done on the data. The viewer should only get data and display it. Marcel P.S. - I will revert to v3.0 for now since there I can (in a twisted way) get almost the needed behavior.
Marcel see Bug 60117 for the discussion on deferred content providers. We don't have a released solution for this yet.
I an equal problem like marcel. (Eclipse M4) I use a TableViewer with the virtual flag. Initially it is empty. Then data are loaded in the table (e.g. one row). After a user interaction the table is cleared through advising the contentprovider to return an array with a length of 0. This works great. But when I set new datarows again (e.g. 1 row) in the empty table an Index out of bounds exception occurs: java.lang.IllegalArgumentException: Index out of bounds at org.eclipse.swt.SWT.error(SWT.java:2813) at org.eclipse.swt.SWT.error(SWT.java:2752) at org.eclipse.swt.SWT.error(SWT.java:2723) at org.eclipse.swt.widgets.Widget.error(Widget.java:388) at org.eclipse.swt.widgets.Table.getItem(Table.java:1232) at org.eclipse.jface.viewers.TableViewer.getCreatedItems(TableViewer.java:383) at org.eclipse.jface.viewers.TableViewer.internalRefresh(TableViewer.java:728) at org.eclipse.jface.viewers.TableViewer.internalRefresh(TableViewer.java:706) I analysed the problem and it is the following: The currentVisibleIndex is only changed in the "setData" - listener attached in addTableListener() in the TableViewer class. This listener is activated if a new row is added in the model, but it is not notificated when the table is "cleared". So on the next internalRefresh the getCreatedItems() table tries to get the item at the first index of the table, but the table is empty.
Todd, we must have someone from SWT look at what you are doing. Keeping a current visible index sounds completely wrong to me.
I agree - I think we should work on this together and I think I might have a better solution but I want to bounce it off of you.
Upping priority. Steve has some ideas for this sort of thing we may address in 3.2.
Steve, do you remember what ideas Tod is referring to?
From memory and this bug report, Tod was attempting to keep a "currentVisibleIndex". In general, this doesn't make sense. The operating system can ask for the contents of any item at any time, even those that are not visible. We need to determine what problem "currentVisibleIndex" is solving and see whether the problem is real and/or if there is already a solution in SWT.
There is no "currentVisibleIndex" kept by TableViewer. Regarding the original problem (lacking support for clear/remove), there is a method TableViewer.clear(), and TableViewer.remove(int index) is missing. Marcel/Martin: Is this still a problem for you?
Removing the target milestone. Please add a comment if you need index-based remove.
Personally, I've worked around this problem by extending the existing class. I do think that TableViewer should have a remove method and any other mehtod that can be directly accessed in Table, even if it is for soundness only.
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. If you have further information on the current state of the bug, please add it. 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.
