Bug 144280 - [Viewers] VIRTUAL TableViewer element removal doesn't work
Summary: [Viewers] VIRTUAL TableViewer element removal doesn't work
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 major with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: helpwanted
Depends on:
Blocks: 154755
  Show dependency tree
 
Reported: 2006-05-29 13:43 EDT by Philippe Detournay CLA
Modified: 2020-11-05 14:06 EST (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Detournay CLA 2006-05-29 13:43:49 EDT
You can't remove an element from a virtual TableViewer. You can't even clear the whole content. The remove method seems to be a no-op.

import org.eclipse.jface.viewers.TableViewer;
import org.eclipse.swt.SWT;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;

public class Test
{
  public static void main(String[] args)
  {
    Shell shell=new Shell(Display.getCurrent());
    shell.setLayout(new FillLayout());
    
    TableViewer table=new TableViewer(shell,SWT.VIRTUAL);

    Object item="item";
    
    table.add(item);
    table.remove(item);
    
    shell.setVisible(true);
    
    while(!shell.isDisposed())
    {
      shell.getDisplay().readAndDispatch();
    }
  }
}
Comment 1 Thomas Schindl CLA 2006-05-30 05:57:40 EDT
The problem starts in VirtualManager#addTableListener(). The code has the "problem" that the table's content is modified before it is shown to the user. So the table-listener is not notified about the "SWT.SetData" and no connection between the tableitem and our model object is known. So it could not be removed. The attached source behaves appropriate:

Shell shell=new Shell(Display.getCurrent());
    shell.setLayout(new FillLayout());
        
    final TableViewer table=new TableViewer(shell,SWT.VIRTUAL);
    final Object item="item";

    table.add(item);
    
    Button b = new Button(shell,SWT.PUSH);
    b.addSelectionListener(new SelectionListener() {

		public void widgetDefaultSelected(SelectionEvent arg0) {
			
		}

		public void widgetSelected(SelectionEvent arg0) {
			table.remove(item);
		}
    	
    });
    
    shell.setVisible(true);

    
    
    while(!shell.isDisposed())
    {
      shell.getDisplay().readAndDispatch();
    }

I'm not sure what could be done to prevent the user from this situation at least is should be documented.


(In reply to comment #0)
> You can't remove an element from a virtual TableViewer. You can't even clear
> the whole content. The remove method seems to be a no-op.
> 
> import org.eclipse.jface.viewers.TableViewer;
> import org.eclipse.swt.SWT;
> import org.eclipse.swt.layout.FillLayout;
> import org.eclipse.swt.widgets.Display;
> import org.eclipse.swt.widgets.Shell;
> 
> public class Test
> {
>   public static void main(String[] args)
>   {
>     Shell shell=new Shell(Display.getCurrent());
>     shell.setLayout(new FillLayout());
> 
>     TableViewer table=new TableViewer(shell,SWT.VIRTUAL);
> 
>     Object item="item";
> 
>     table.add(item);
>     table.remove(item);
> 
>     shell.setVisible(true);
> 
>     while(!shell.isDisposed())
>     {
>       shell.getDisplay().readAndDispatch();
>     }
>   }
> }
> 

Comment 2 Boris Bokowski CLA 2006-05-30 13:15:05 EDT
Sorry, I don't understand what this bug is about. Your TableViewer instance is not set up properly (you need a content provider and an input, and a label provider).

There is a bug in TableViewer.remove for the virtual case, see bug 97786.
Comment 3 Philippe Detournay CLA 2006-05-30 14:42:55 EDT
After a couple of hours struggling against my full software to manage to isolate the problem, here is a quick code demonstrating the problem I have with the element removal on VIRTUAL tables.

The logic is as follows:
Initially the table is empty, it contains no element.
Then, some external trigger occurs (here a button), and three items are added into the table.
Then, some new external trigger occurs (here the button again), and the three previously added elements are removed.
Finally, a last trigger occurs (still my lovely button), and the three items get readded. Well actually they don't, because I get an AOOBE instead.

Note that removing the VIRTUAL attribute solves the problem.

I'm not quite sure this is a duplicate of bug 97786, but if it is, well... do you plan to fix it someday? :)

import org.eclipse.jface.viewers.IStructuredContentProvider;
import org.eclipse.jface.viewers.TableViewer;
import org.eclipse.jface.viewers.Viewer;
import org.eclipse.swt.SWT;
import org.eclipse.swt.events.SelectionEvent;
import org.eclipse.swt.events.SelectionListener;
import org.eclipse.swt.layout.RowLayout;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;

public class Test
{
  private static class MyContentProvider implements IStructuredContentProvider
  {
    private TableViewer _viewer;
    private int _step=0;
    private Object[] _items=new Object[] {"one","two","three"};

    public Object[] getElements(Object arg0)
    {
      switch(_step)
      {
        case 0:
          return new Object[0];
        case 1:
          return _items;
        case 2:
          return new Object[0];
        case 3:
          return _items;
      }
      
      return new Object[0];
    }

    public void dispose()
    {
    }

    public void inputChanged(Viewer arg0,Object arg1,Object arg2)
    {
      _viewer=(TableViewer)arg0;
    }
    
    public void nextStep()
    {
      _step++;
      switch(_step)
      {
        case 1:
          _viewer.add(_items);
          break;
        case 2:
          _viewer.remove(_items);
          break;
        case 3:
          _viewer.add(_items);
          break;
      }
    }
  }
  
  public static void main(String[] args)
  {
    Shell shell=new Shell(Display.getCurrent());
    shell.setLayout(new RowLayout());

    final TableViewer table=new TableViewer(shell,SWT.VIRTUAL);
    
    final MyContentProvider provider=new MyContentProvider();
    
    table.setContentProvider(provider);
    table.setInput("input");

    Button b1=new Button(shell,SWT.PUSH);
    b1.addSelectionListener(new SelectionListener() {

      public void widgetSelected(SelectionEvent arg0)
      {
        provider.nextStep();
      }

      public void widgetDefaultSelected(SelectionEvent arg0)
      {
      }});
    
    shell.setVisible(true);

    while(!shell.isDisposed())
    {
      shell.getDisplay().readAndDispatch();
    }
  }
}
Comment 4 Boris Bokowski CLA 2006-05-30 14:56:16 EDT
Thanks for the snippet! This does not look like a duplicate of bug 97786. As a workaround, does calling refresh() work?
Comment 5 Thomas Schindl CLA 2006-05-31 05:41:38 EDT
Boris as you may see from the code I added the problem is that the "SWT.SetData" event only occurs if you have opened the shell and because the tableItem#setData(modelobject) only happens if this table event is triggered the removal of elements using tableViewer#remove(modelobject) is NOT working until you have opened the main shell! As far as I can see this has nothing todo with content-providers, ...

(In reply to comment #2)
> Sorry, I don't understand what this bug is about. Your TableViewer instance is
> not set up properly (you need a content provider and an input, and a label
> provider).
> 
> There is a bug in TableViewer.remove for the virtual case, see bug 97786.
> 

Comment 6 Thomas Schindl CLA 2006-05-31 06:05:11 EDT
(In reply to comment #3)
> After a couple of hours struggling against my full software to manage to
> isolate the problem, here is a quick code demonstrating the problem I have with
> the element removal on VIRTUAL tables.
> 
> The logic is as follows:
> Initially the table is empty, it contains no element.
> Then, some external trigger occurs (here a button), and three items are added
> into the table.
> Then, some new external trigger occurs (here the button again), and the three
> previously added elements are removed.
> Finally, a last trigger occurs (still my lovely button), and the three items
> get readded. Well actually they don't, because I get an AOOBE instead.
> 
> Note that removing the VIRTUAL attribute solves the problem.

I've tried this bug with the fix given in bug #144406 and its working as expected:
1st Button press: 3 items are added
2nd Buttun press: 3 items are removed
3rd Button press: 3 items are added

So it seems this fixes your main problem what stays unfixed is the problem demonstrated in your first snippet where the structure changes are not propagated because they happen before the main shell is opened.
Comment 7 Tod Creasey CLA 2006-08-16 13:07:25 EDT
Boris if you are not planning to address this for 3.2.1 you should remove the tag. The release candidates start next week.
Comment 8 Boris Bokowski CLA 2006-08-22 16:53:07 EDT
I will attach a patch to bug 154755 but leave this one open to track the
particular issue reported here.

Unfortunately, there are just too many changes required to fix the problems
with VIRTUAL TableViewer so we have to move this to 3.3.
Comment 9 Boris Bokowski CLA 2007-05-28 23:27:21 EDT
I hope we can get to this in 3.4.  In 3.3, I ended up spending so much time on the virtual tree (which is used by Debug) that I never got to look at virtual tables.
Comment 10 Boris Bokowski CLA 2008-05-02 14:56:24 EDT
Mass update - removing 3.4 target. This was one of the bugs I marked for investigation (and potential fixing) in 3.4 but I ran out of time. Please ping on the bug if fixing it would be really important for 3.4, and does not require API changes or feature work.
Comment 11 David Pérez CLA 2008-08-13 10:01:56 EDT
Any known workaround?
Comment 12 Boris Bokowski CLA 2008-08-13 10:04:33 EDT
(In reply to comment #11)
> Any known workaround?

To which exact problem?  Could you file a new bug with a snippet for me to look at?
Comment 13 David Pérez CLA 2008-08-13 10:12:42 EDT
I used to have this code:

  remove_the_object_from_my_content_provider();
  viewer.remove(deletedObject);

but doesn't work well due to this bug.

So, I have tried now this logic for removing an object:

  remove_the_object_from_my_content_provider();
  viewer.setItemCount(viewer.getTable().getItemCount()-1);
  viewer.refresh();

but it doesn't refresh well my data.

What do you recommend me to do?
Comment 14 David Pérez CLA 2008-08-13 10:26:32 EDT
My problem is this:

I have a table viewer which manages a table with the virtual style, and a
content provider that implements ILazyContentProvider.

When I delete a single object, first I delete from my content provider and then
I invoke tableViewer.remove(deletedItem).

Sometimes, the item count of the table isn't decreased, and the deleted item is
showed twice.  I could spend some time getting a simple snippet showing the
problem, but I think I don't need to invest this time, as this is an already
known problem.

Example:

I have these items in my table viewer:

A
B

and I delete the A item (the selected index).
The viewer then shows this:

B
B
Comment 15 Boris Bokowski CLA 2009-11-26 09:52:18 EST
Hitesh is now responsible for watching bugs in the [Viewers] component area.
Comment 16 David Pérez CLA 2011-02-23 03:42:09 EST
It's incredible such an old and basic bug isn't yet solved.
Probably because few people use virtual tables.
Comment 17 Lars Vogel CLA 2018-11-15 06:11:18 EST
Mike, something for you?
Comment 18 Eclipse Genie CLA 2020-11-05 14:06:03 EST
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.