Community
Participate
Working Groups
1. Open an editor. 2. Place the cursor somewhere. 3. Open another editor. 4. Place the cursor somewhere. 5. Ctrl+PgUp to go back to the first editor. 6. You cannot start typing. You have to hit 'Tab' to switch focus to the editor's actual text control.
You can also reproduce the problem when switching editor tabs with the mouse. It seems that SWTPartRenderer's requiresFocus(MUIElement) method is returning 'false' when you swap tabs in a tab folder. This was added to support bug 319063.
Created attachment 174638 [details] Patch I looked around a bit and made this modification to the PartServiceImpl. I guess it should activate a part when it is changed but I could be totally wrong because I have no ideas how this internals are working. To me this fixes the activation problem.
The real problem is in the SWTRenderer#requiresFocus() implementation which returns false when AbstractPartRender#activate(MPart) is called (which calls out to PartServiceImpl#activate(MPart,requireFocus))! The patch only fixes the symptom. One more note on this is that PartServiceImpl#activate(MPart,requireFocus)) is called twice
Overloading ContributedPart/StackRender#requireFocus() and returning true fixes the problem. I think the problem here is that when the internal event is processed for SWT the focus control is already our Editor and so we get false.
Created attachment 174648 [details] patch
Created attachment 174649 [details] patch
I can't comment on the patch but do feel that the fix should be in the renderer code instead of the EPS.
(In reply to comment #7) > I can't comment on the patch but do feel that the fix should be in the renderer > code instead of the EPS. The last patch does the fix in the renderer!
(In reply to comment #8) > (In reply to comment #7) > > I can't comment on the patch but do feel that the fix should be in the renderer > > code instead of the EPS. > > The last patch does the fix in the renderer! Yes, I realize that. What I meant was, "I can't comment on whether your new patch is correct or not but do agree that the fix belongs in the renderer".
Eric, I think we need your input on this. As described earlier the problem is that the requiresFocus calculation is wrong when the editor is already created. I fixed this by overloading this in ContributedPartRenderer while we are processing the activation event.
Wouldn't it be safer if the code was something like the following? + protected boolean requiresFocus(MPart element) { + if (element == partToActivate) { + return true; + } + return super.requiresFocus(element); ((Composite) widget).addListener(SWT.Activate, new Listener() { public void handleEvent(Event event) { - activate((MPart) me); + try { + partToActivate = me; + activate((MPart) me); + } finally { + partToActivate = null; + } } });
Looks good.
Created attachment 174928 [details] updated patch as per suggestion
beauty +1
Committed to HEAD (I'm counting comment 12 as Tom's +1)
There's still one very small activation problem. When you launch an already existing workbench the correct editor tab is restored but it is not activated (tab background white, no focus transfered to editor). Should I file an extra defect for this?
(In reply to comment #16) > When you launch an already > existing workbench the correct editor tab is restored but it is not activated > (tab background white, no focus transfered to editor). That's a general problem due to not having activation history. See bug 300742 and bug 320476.
This one can be marked as fixed, right?
yes
Verified with I20100726-2152 on Windows XP.
