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

Bug 227039

Summary:	[package explorer] status bar description not updated when selected's label changes
Product:	[Eclipse Project] JDT	Reporter:	Tracy Hodges <tracy.hodges>
Component:	UI	Assignee:	JDT-UI-Inbox <jdt-ui-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	emoffatt, martinae
Version:	3.3.2
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Tracy Hodges

2008-04-14 17:42:37 EDT

Build ID: M20080221-1800

Steps To Reproduce:
1. With any Java project, expand a .java file down to the method level. Select a method that has at least one parm. In my case the method was named 'testMethod(int parm1)'.
You should be able to see the method's signature in the status bar.
2. Execute the menu item 'Refactor->Change Method Signiture' on the method. Change a parameter's name. In my case, I changed 'parm1' to 'parm1changed'. Press 'Finish'.
3. The status bar should still show the old parm name.
4. Reselect the method in the 'Package Explorer'.
5. The status bar should have been updated with the new parm name.

Changing other stuff, like the parm types etc will update the status bar, because I believe the tree label gets updated. However what is doing that is not the Common Navigator stuff, but instead probably the Java extensions.

More information:
CommonViewerManager has support for adding a ISelectionChangedListener to update the status bar when the selection changes. It uses the ILabelProvider of the commonViewer, if it implements IDescriptionProvider also.

If the treeViewer is refreshed (with labels updated), a LabelProviderChangedEvent may be fired for the selected item. The getText method of the ILabelProvider will be invoked and the Tree updated. However, the status bar at the bottom will not be updated automatically, since the selection did not change.

I was able to work around this by calling viewer.setSelection(viewer.getSelection()) at the same place I refresh the viewer.

It seems to me that CommonViewerManager that is managing the status bar for the viewer, should be sensitive to the same LabelProviderChangedEvents somehow.

I had to work hard to reproduce this without my application. It is rare in the PackageExplorer for an item to display data that you can get changed without something refreshing the status bar, but I found one case.

Comment 1 Eric Moffatt

2008-04-15 13:27:35 EDT

I'm a bit confused...;-). Does the Package Explorer work and the Project Explorer doesn't ?

Comment 2 Tracy Hodges

2008-04-15 13:39:43 EDT

The Java Package Explorer uses the CommonNavigator.   (Or at least I think it does.)

The problem is with the CommonNavigator.  I only used the Java Package Explorer to try to get an easier recreation process.   I originally found the problem with my usage of the CommonNavigator, but using my application in recreation steps would be hard.

In my usage, an item's label can change 'programmatically'.   Basically the label displays a state of the item (i.e. Open, Closed, etc).   There are actions that change the state, but do not cause the selection to change.   When that happens, the label in the tree gets refreshed, but the status bar does not. 

It does not get refreshed, because the selection never changed.   However, it was based on the same label provider the tree used.   Seems like the 2 should work together.

Comment 3 Eric Moffatt

2008-04-16 15:50:09 EDT

Tracy, the Package Explorer is a completely separate implementation from the -Project- Explorer (aka CommonNavigator). That's why determining which of the two show the defect is important; if only one does then it's likely a defect in it's implementation, if both show it there's more likely to be a deeper underlying cause...

So, can you tell me which of the two views show this defect?

Comment 4 Eric Moffatt

2008-04-18 16:03:53 EDT

OK, I just tried the scenario in both the Package and Project Explorers...same result, no update to the status line.

Passing to JDT for the first look...

Comment 5 Martin Aeschlimann

2008-04-21 05:21:25 EDT

As Eric says, the code for the package explorer is not related to the common navigator. Both have the same bug.

I see the bug, but I'm not sure if we should do something about it. Looks rather minor to me.

Comment 6 Eclipse Genie

2019-11-01 02:45:52 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.

--
The automated Eclipse Genie.