Community
Participate
Working Groups
build I20050420-1200 - open a compare editor from the sync view - the compare editor is active, but the sync view still has focus (filed as bug 92257) - give the editor focus - Window > Show View > Other > PDE > Plug-ins - the Plug-ins view is active, but the editor still has focus (filed as bug 92256) Although the compare editor and Plug-ins view should be fixed to properly implement setFocus(), the workbench should ensure that if a part is active, it had focus, by setting (or forcing) focus on the part's control if its setFocus() method did not. The workbench used to do this in 2.1.
Fixed in head. This regression was caused by an optimization intended to remove duplicate focus events for well-behaved editors. The new behavior should work in all situations with fewer duplicate focus events.
Reopened. My naive solution caused more problems than it fixed. Trouble is, it's hard to tell if a part's setFocus did anything or not... and if you get it wrong and try to force focus to the part's control or the tabs, you end up putting focus in the wrong spot for well-behaved parts. The obvious solution (checking if the part has focus after the setFocus call) doesn't work -- there may be a modal dialog open or the window may not be visible yet, in which case SWT actually sets "saved focus" in the setFocus call. The real focus only changes once the shell becomes both visible and active. We could try setting focus first to the presentation, then to the control, then calling setFocus on the part (each call overwriting the effects of the previous one)... but that would be really inefficient. I believe the best solution is to either get SWT support to monitor the effects of setFocus or to manage our own "saved focus" pointer. The saved focus pointer will point to the control we want to have focus, and we'll only set the real focus once the part becomes visible in the active shell. In this specific situation, checking if the control has focus after the call to setFocus should work.
Not for 3.1. The fix is going to be complicated.
What's the downside to just doing a setFocus() on the pane before the part? If performance is a concern, how bad is it?
Actually, to handle the case where none of the part's controls take focus (e.g. empty Outline view), a forceFocus() may be necessary.
The trouble is, it's hard to tell what the performance impact is because each focus change could fire events to client code. It may also cause flicker if the client code is changing the colour of the widget with focus (...or if the OS is doing this for free). I agree that we should be tolerant of buggy setFocus methods, but only if this has no adverse affects on well-behaved parts.
> Trouble is, it's hard to tell if a part's setFocus did anything or not... You could use an SWT.Activate listener on the Composite which gets passed to a part. If you get the activate event, then you know some child of that composite obtained focus. The problem would just be to defer your expectations until the shell is opened and active. forceFocus() shouldn't be used if the control displayed is not even focusable. In that case, you should probably put focus on the Part presentation such as the CTabItem.
Is this still a problem in 3.3? PW
Yes, it's still a problem in 3.3. Steps to reproduce: - create a new plug-in project using the "Plug-in with a view" template - in the generated view class, delete the setFocus() method or comment out its body - run the target - give focus to the Navigator view - show the new view - the Navigator still has focus.
investigate PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
