Bug 31135

Comment 1 Dirk Baeumer 2003-02-09 08:22:46 EST

Martin, I guess that someone has to do a reconcile on the CU. Is this us or 
Core ?

Comment 2 Martin Aeschlimann 2003-02-10 06:40:33 EST

I looked at the delta send by the sorter. the outliner doesn;t react to it, as 
there are no additions or deletions.
The type is marked as changed - children changed
The type's sorted elements are marked as changed - content changed

So I think the outliner is correct, as the same delta would be send if in each 
of the members a whitespace would be added. A non-structural change where no 
refresh of the type is needed.

There must be a way that the delta can signal that children changed but also 
the the type must refresh. Maybe the type could also have the F_MODIFIERS flag 
included?

Moving to JCore

Comment 3 Olivier Thomann 2003-02-10 16:24:40 EST

The sort operation doesn't send any delta. It simply update the buffer of the
working copy passed as an argument.

Comment 4 Philipe Mulet 2003-02-12 06:47:10 EST

Just to clarify. The sorting operation doesn't answer a custom delta, but 
rather relies on working copy fine grain deltas (when buffer changes).

Actually, we reproduced the problem without using sort members. 
- If you have unit with
class X { 
  void foo(){}
  void bar(){}
}

- copy both method sources at once
- swap foo() and bar() in editor, observe that bar() is listed before foo() in 
outliner.
- paste back the copied source, and notice that the outliner won't refresh 
(order is now wrong).

Fine-grain deltas should be able to detect reordering scenario, based on 
ordering of handles.

Comment 5 Jerome Lanneluc 2003-02-13 12:56:11 EST

Added new flag to signal a change in the order of the element: F_REORDER.
So when members are reordered, the affected members have a CHANGED delta with 
the F_REORDER flag positioned.

Note this won't be in today's integration build, but in next integration build 
(20030218)

Moving to JDT/UI to react to this new flag.

Comment 6 Dirk Baeumer 2003-02-13 13:33:52 EST

I guess this affects all the content providers that deal with members (e.g 
package explorer, outliner and members view).

Have to see if we have to do something in the UI.

Comment 7 Jerome Lanneluc 2003-02-13 17:38:59 EST

Note this is not an API change. If you choose not to change anything on the UI 
side, the behavior will be the same as before. However to fix this bug you will 
now need to check the F_REORDERED flag (and not F_REORDER as I previously 
indicated)

Comment 8 Dirk Baeumer 2003-02-18 12:38:31 EST

Members view and package explorer updates correctly. So only the outliner is 
affected.

Comment 9 Dirk Baeumer 2003-02-19 05:25:47 EST

Fixed by detecting the reorder case and executing a refresh.

Comment 10 Dani Megert 2003-02-25 12:25:06 EST

Build 2.1 RC1

Does not work for Members view.

Test Case
1. Open Java Browsing perspective
2. Add type T:
public class T {
	int a;
	int b;
}
3. From the editor's context menu: Source -> Sort Members

Note: Maybe this is a side-effect of using refresh(false). If this is the case
then this must not be fixed by reverting to refresh(true) since this would cause
lots of refreshes in the Java Browsing perspective and would invalidate PRs
fixed for RC1.

Comment 11 Dirk Baeumer 2003-02-26 13:51:21 EST

Daniel, can you look into the members view. You know the code better than I. If 
it is too tight move it back to me.

Comment 12 Dani Megert 2003-02-27 02:07:16 EST

Sure.

Comment 13 Dani Megert 2003-02-27 06:06:49 EST

OK. This is a result of misunderstood REORDER flag. I assumed that the reorder
flag is set on the parent and not on each child.

Comment 14 Dani Megert 2003-02-27 12:37:38 EST

I have now reverted parts of my code to use refresh(Object, true). This can be
viewed as a workaround for a bigger problem:

The TreeViewer does not handle structural changes correctly if the updateLabels
flag is false. I assume that the children are ignored if the viewer's label
didn't change.

Small Test Case:
0. From your development workspace start an Eclipse target
1. In the target add the following CU and save it:
public class C {
	int b;
	int a;	
	public class Inner {
		void foo() {
		}
	}	
}
2. Source -> Sort Members
   Observe: the Members view is OK
3. Exit target
4. In the development workspace open JavaBrowsingContentProvider.java and
replace the only occurrence of postRefresh(null, boolean) with postRefresh(null).
5. Start target
6. Open C
7. Source -> Sort Members
   Observe: the Members view is totally corrupted. Clicking in the Members view
reveals the old elements

Comment 15 Dani Megert 2003-02-27 12:39:58 EST

Probably a duplicate of bug 32414

Comment 16 Nick Edgar 2003-03-05 22:44:52 EST

I'm curious.  In JavaBrowsingContentProvider.postRefresh(Object, boolean) you 
have:
 		if (!updateLabels) {
			postRefresh(root);
			return;
		}

Why do you need this test?  You should be able to just pass the boolean to the 
viewer refresh.

Comment 17 Nick Edgar 2003-03-06 01:39:22 EST

*** This bug has been marked as a duplicate of 32414 ***

Comment 18 Dani Megert 2003-03-10 05:20:05 EST

>Why do you need this test?  You should be able to just pass the boolean to the 
>viewer refresh.
Correct. I did it this way to see that it's a workaround for this bug. Normally
postRefresh(Object) should be called.

I added a new bug to revisit refresh calls in the JavaBrowsingContentProvider
(bug 34260).