Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 140349

Summary:	[Viewers] Viewer#remove() Trys to select previously removed Elements
Product:	[Eclipse Project] Platform	Reporter:	Benjamin Pasero <bpasero>
Component:	UI	Assignee:	Platform UI Triaged <platform-ui-triaged>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	bokowski, Michael.Valenta, Mike_Wilson, mlists, Tod_Creasey, tom.schindl
Version:	3.2
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Benjamin Pasero

2006-05-05 09:24:22 EDT

Version: 3.2.0
Build id: I20060428-1315

I am a bit surprised how an AbstractTreeViewer is trying to preserve the Selection on a remove() call. If the Objects that are to be deleted are part of the Selection, the Viewer tries to restore the Selection to Objects which are no longer part of the Content.

The Viewers should be smart enough to remove those Objects from the Selection that have just been deleted.

Ben

Comment 1 Benjamin Pasero

2006-05-05 10:27:47 EDT

Looks like a regression due to Bug 125708. I dont see this behaviour in RC2.

ben

Comment 2 Boris Bokowski

2006-05-05 10:40:46 EDT

Does this cause any exceptions, or is it just surprising behaviour?

Comment 3 Benjamin Pasero

2006-05-05 10:44:19 EDT

It is just surprising behaviour. I get a Callback into my ContentProvider#getParent() with the element that just got deleted. I do some lookup then to get the parent, but since the element was deleted before, my model fails to resolve the parent.

Ben

Comment 4 Boris Bokowski

2006-05-05 10:57:10 EDT

I agree that this is surprising behaviour, but I am quite sure that this behaviour was there for a long time, i.e. even before TreeViewer was changed to allow multiple equal elements and to use TreeSelection.

Comment 5 Eric Moffatt

2006-05-05 13:40:01 EDT

Susan, comments??

Comment 6 Benjamin Pasero

2006-08-30 19:00:35 EDT

Could this be considered for 3.3? Actually what would be cool to have is a feature that selects the next item that is following the deleted one. This would extend the meaning of presering the selection a bit, but its something that I often implement on my own.

Ben

Comment 7 Boris Bokowski

2006-08-30 20:22:21 EDT

Would you like to contribute a patch for this, Ben?

Comment 8 Boris Bokowski

2006-08-30 20:23:40 EDT

Even better than a patch, and maybe easier to write: a test case (new method for SimpleTableViewerTest/SimpleTreeViewerTest) that defines the desired behaviour.

Comment 9 Benjamin Pasero

2006-08-31 03:46:02 EDT

Sure. I can attach a patch soon.

Ben

Comment 10 Boris Bokowski

2009-11-26 09:43:12 EST

Hitesh is now responsible for watching bugs in the [Viewers] component area.

Comment 11 Eclipse Webmaster

2019-09-06 15:30:53 EDT

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.

Comment 12 Eclipse Genie

2022-01-06 09:39:13 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.