| Summary: | [Decorators] Flashing viewer refresh | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Knut Radloff <knut_radloff> | ||||||
| Component: | UI | Assignee: | Tod Creasey <Tod_Creasey> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P2 | CC: | airvine, daniel_megert, n.a.edgar | ||||||
| Version: | 2.0 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 2000 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Knut Radloff
Created attachment 3160 [details]
Screen shot showing one flashing state
Outliner and search view are both flashing
Created attachment 3161 [details]
Screen shot showing another flashing state
Outliner stops flashing, search view still flashes.
The flashing stopped in both views when I closed the open Transfer.java editor. Do you have anything in your .log? Only jdi TimeOutExceptions. I saw the same behaviour on the 200301151011 build. I had also just finished a search. In my case the flashing stopped when I openned an .html document within eclipse. It then started again when I started cycling through the searched documents via the navigation buttons of the search view. Nothing in the log. Replicated in 20030127 The problem appears to be related to how the Java Outline and the Problem Marker manager interact (I am having some trouble with out of memory errors so debugging has been a challenge). I am adding Dani to the cc list as he likely has some insight. The problem seems to go this way: 1) Double click on an entry in the search view to open it 2) This causes the outline view to populate which then calls the decorator 3) Decorator will eventually send a labelProviderChanged 4) Problem marker picks this up and sends its own label provider changed 5) Decorator has already returned the answer from the first request so it fires off a second one 6) Cycle continues until the OutlineView gets a different input (switch editor). I am not sure about the transition from 3 to 4 - perhaps Dani can shed some light. Turns out that the problem was with adaptability. I was storing the result in terms of the JavaElement and the SearchView was asking for it for the IFile. As a result I was queueing another decoration and around it went. We now cache the adapted result and the adapted+original result and send updates for the original. Well spotted Knut - this was a toughie. Fixed in build >20030128. *** Bug 30882 has been marked as a duplicate of this bug. *** Marking closed |