Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #141102 +++ Call Hierarchy defined as a tabbed view Package Explorer is defined as a Fast View Start on Class A (any class) Go to a method and Right Click on Open Call Hierarchy Click on a class other than the current one (Class B) Note: Class B is now active in the editor Open the Package Expolorer Package Explorer has Class A still highlighted (instead of Class B) Click on the editor (which still has Class B) Open the Package Expolorer Package Explorer has Class B is now correctly highlighted Click on the editor +++ The solution is to update with partBroughtToTop(*) as well PW
Can not reproduce in I20080408-0800. I followed the steps and when I open the package explorer, the new class (B) is selected. Also seems to work in the Project explorer.
Build id: I20080408-0800 I'll admit that the original steps are not very specific, I was having problems reproducing them too. I'll try to rephrase it properly: 1. Open 'Package Explorer' as a regular view. 2. Select 'Link with Editor'. 3. Open ClassA. 4. Invoke 'Call Hierarchy' on one of its methods. 5. Double-click on one of the calling classes in the 'Call Hierarchy' view to open ClassB. 6. The 'Package Explorer' view shifts as expected. 7. Select the original method again in the 'Call Hierarchy' view. 8. The 'Package Explorer' view does not shift. 9. Click back and forth between the two, notice that the 'Package Explorer' never moves. 10. Double-clicking will cause the view to shift properly. I seem to have a different problem entirely with defining it as a fast view wherein the view does not shift after step 5. I am not sure if they are related.
The problem is here that the editor is only made visible, but not active. The question is, should the package explorer track the editor that got visible last: If yes, then we should listen for partVisible. But what does that mean if you have several editors shown at the same time? I think we should not change anything here.
(In reply to comment #3) > The problem is here that the editor is only made visible, but not active. > > The question is, should the package explorer track the editor that got visible > last: If yes, then we should listen for partVisible. It looks partBroughtToTop(*) should be used, which notifies that an editor (or view) has been brought to the top programmatically (without the need for activation). However, in the split editor stack partBroughtToTop(*) is only fired when you would want for the top stack, not the bottom one. I've opened bug 226288 to track this issue. I'm fine with leaving this as a WONTFIX until UI can figure out the correct way to make it work :-) PW
