Community
Participate
Working Groups
3.3 M3 In the attached example, when setFocus() is called on the shell, it ends up giving focus to the Canvas (which should not take focus), instead of the Text. Steve says: Looks like a bug. If you click in the text, then you can't tab into the canvas. Does this code really represent what you are seeing? Nick replies: > If you click in the text, then you can't tab into the canvas. I don't want it to do that. The canvas should never take keyboard focus, since we're not hooking a key listener on it - it's just for visual display of an icon or throbber (I know you'll just love that word). I expected it to find the first control that could take focus when the containing composite is told to setFocus(). Instead, the first Composite (in a depth-first traversal) gets focus if its children can't take focus, so focus is hidden. It's this latter problem that we're facing. By default, the editor framework sets focus on the editor's outermost control. In this case, its structure is like: Composite A Composite B AnimatedLabel (a Canvas without key listener) Label Composite C Text So when it does A.setFocus(), the AnimatedLabel gets focus (hidden) instead of the Text. There's some other intermediate composites thrown in there just for fun, but that's the gist of it. Steve responds: I agree. We have a bug. I meant that when you clicked on the text and hit tab and it didn't traverse, it confirmed our bug even more. Enter a bug report, CC me and we will fix it.
Created attachment 56960 [details] Snippet showing the problem
We won't get to this for 3.3.
*** Bug 237882 has been marked as a duplicate of this bug. ***
NOTE: This needs to be fixed too: "If a Composite has only no focusable children (e.g. Labels), setFocus() call for that Composite returns true and the focus is set to that Composite, even though it cannot receive focus."
*** Bug 237886 has been marked as a duplicate of this bug. ***
NOTE: When focus is assigned to a composite before a shell is opened, then none of the children take focus and the composited is remembered as the saved focus control. Ensure that this case is fixed when this bug is fixed.
*** Bug 237888 has been marked as a duplicate of this bug. ***
NOTE: Ensure that tabList() is taken into account when setting focus.
What is the correct behavior when setting focus on a Canvas, when both the Canvas and a child can have focus? It seems to be depth-first/post-order selection (the child gets focus), so we're using forceFocus() when we want the Canvas to get focus. Another strange thing is that we're doing this on MouseDown on the Canvas. If the canvas can hold focus, shouldn't it get it "for free" on mousedown?
This still reproduces with SWT 3.4. Is there any plan to fix it? While ago, I filled several bugs that all have something to do with this one (see bugs marked as duplicate of this one). Today, I spent several hours debugging another focus problem which again related to this one (TAB traversal failed in forward direction, because there was Composite with no-focusable children only, that stole the focus. In backward direction it worked).
This also burns us when setting the focus into the status text editor composite: instead of giving the focus to a button which is in the second child composite it forces the focus on the first one which only has labels in it.
Ping.
Not sure we can change this behaviour. Calling setFocus() in a composite will cause it call setFocus() in all its children (in the same order they were created). Calling setFocus() on Canvas will give focus to it (Note: by default Canvas don't take part on tab navegation and don't take focus on mouse down, but calling setFocus() on it works). You can: a) Change the order setFocus() is called on the children by using canvas.moveBelow(text); b) create the canvas with SWT.NO_FOCUS Silenio, anything to add ?
Running the snippet and hitting tab causes the Text to get focus. I am pretty sure this is correct behaviour. Once the Text gets focus it doesn't lose it. AFAICT this is correct. Can anyone confirm? If not I will close this bug in a bit. Bug triaged, visit https://wiki.eclipse.org/SWT/Devel/Triage for more inforamation.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
Still a relevant issue: There is different focus behavior between the OS default and SWT behavior. e.g. win32 prefers tab-stop to get focus over the first control. Note there is different interpretation of what a focusable control is. When set SWT.NO_FOCUS it is not focusable, but how about items that are not tabItem? Also, SWT doesn't respect its own tab-order in setFocus. Note that Comment 7 is fixed in Bug 297510.
