Community
Participate
Working Groups
Build 20030716 I am working with 3 Java perspectives open at the same time. When developping code in one (with autobuild off), and pressing ctrl-S, then ctrl-B, it sometimes decide to bring to front another Java perspective. I am guessing it is doing so to force reconciling another opened Java editor sitting in a different perspective (which it shouldn't, or at least should do in background).
Does it do this if you invoke Save and Build via the menus rather than using the accelerators? Could be a dup of bug 40303 if it's targetting the other window and bringing up a progress dialog there.
If not, do you have concrete steps to reproduce this?
If building from the menu or the build button, then it works as expected (no perspective switching). I have 3 windows with Java perspectives open, and I keep working in one or another (one has a debug perspective in it as well, another has the cvs perspective in it).
To reproduce: 1. Take build I20030717 2. Start a fresh workspace 3. Import the attached preferences 4. Open Java perspective 5. Create new Java project 'Test' 6. Create class 'X' in default package of 'Test' 7. Open Debug perspective 8. Go back to the Java perspective 9. Ctrl-B Observe: After the build, the Debug perspective has focus
Created attachment 5501 [details] preferences file to import
I confirm problem is still there in 20030617. It seems to be confused by the fact that 2 windows have an editor open on the same file. Then one of the 2 editor will incorrectly trigger the other perspective to the front. However Jerome's steps seem to imply it is only a perspective issue (inside same window can occur as well).
Actually, with my preferences, opening a new perspective opens it in a new window.
Jerome has his prefs set to open perspectives in a new window. There's therefore no file open in the Debug perspective, so it can't be the editors triggering window activation. I think Ctrl+B gets sent to the Debug perspective's window instead of the Java perspective's, brings up a progress dialog there, which has the side effect of bringing the window to front. The fact that the menu items work properly supports this. This sounds like a dup of bug 40303, but should verify once that's fixed. *** This bug has been marked as a duplicate of 40303 ***
I think you are right. I thought I had guessed the pattern, but indeed I checked that the progress is shown in wrong context, and so feel like the key binding issue.
