Community
Participate
Working Groups
Build Identifier: 3.6.0 N20100509-2000 When moving between items in the Package Explorer tree view (e.g. by pressing the up and down arrow keys), a focus event is fired for the previously focused item before the focus event for the newly focused item is fired. This causes screen readers to announce the previously focused item before announcing the newly focused item, which makes using this tree view extremely tedious. I notice that this tree view is a SysTreeview32 control. This does not normally happen for these controls. Also, it happens in some other tree views such as the Problems tree view, which I assume uses the same control. Reproducible: Always Steps to Reproduce: 1. Open a project in Eclipse and navigate to the Package Explorer tree view. 2. Move to the first item in the tree (the root) by pressing home. 3. Ensure that the root item is expanded. 4. Press down arrow. Result: A focus event is fired for the first item, followed by a focus event for the second item. Expected: Only a focus event for the second item should be fired.
Hi, Jamie. Thank-you. The Tree control in the SWT Control Example does not fire the extra OBJ_FOCUS. So the source of this problem is somewhere in the Eclipse UI framework code. Oleg, this is a JFace or UI bug. To see the problem, run AccEvent32.exe, and under Options->Settings... select OBJ_FOCUS in the Events: list, then OK. You probably also want Options->On Top. Use Edit->Clear to clear the AccEvent display. (If you don't have AccEvent32.exe, then you can get it here: http://www.microsoft.com/downloads/details.aspx?familyid=3755582a-a707-460a-bf21-1373316e13f0&displaylang=en) Now run ControlExample and go to the Tree tab and use arrow keys to traverse the items. You see only one OBJ_FOCUS per down arrow. Now in the Eclipse Package Explorer do the same thing. There are 2 OBJ_FOCUS events, like Jamie mentioned in comment 0. Why?
Is there a place in SWT code that those messages go through? (Such as an accessibility support firing the event or an object created for event?) That would allow me to track down the source.
No - it's completely native. We do see the key down happen in Tree.WM_KEYDOWN, if that helps give you somewhere to put a breakpoint, however in the end we just pass it through to the native WindowProc for SysTreeView32. After the WM_KEYDOWN WindowProc does its thing (presumably it sees that a down arrow key was pressed and decides to move the selection down to the next item), then one or more WM_PAINT WindowProcs will eventually redraw the selection highlight. We are not doing any SWT accessibility support for this control - it is pure MSAA.
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.
