Community
Participate
Working Groups
Stable: 20020125 When a fast view is visible pressing escape should hide it.Escape is a common action for dismiss. /Greg
*** Bug 9408 has been marked as a duplicate of this bug. ***
This feature request cannot be implemented at the moment. SWT has no support for grabbing key events before the widget processes them. Therefore, we would need the view to hook-up a key listener on all its widgets and notify the workbench when the escape key is hit. We all remember the problems we ran into in the past when we required views to notify us of focus events. I can't add a menu item like "Minimize Fast View ESC" because then the Esc key would be consumed by the accel table handling (even if the item is disabled). Unless someone has another option, I recommend we resolve this pr as LATER and move it to the SWT component.
We should hang onto the PR and flag it as another use case for better key handling from SWT. I tried mapping ESC to activate editor early in the accessibility work, but ran into the problems you describe when it's defined as an accelerator. If we could get the key event from SWT before processing by accelerators, then we could do this, and it would address the fast view use case.
The ESC key current comes in via the traversal mechanism. We already support "climbing" versions of some of the traversal keys (eg. for handling the tabs in a tabbed folder). We can make ESC handling work the same way, although there could be side-effects if some widget in the parent-child tree believes that it is handling ESC traversal. SN to implement _if_this_ok_ with the UI team. KH to indicate if this is wanted.
Tried adding traverse listener for ESC on the shell, which activates the current editor, which has the side effect of minimizing any active fast view. The traverse listener does get called now, however it also gets called when inapproriate, e.g when doing a rename in the Navigator or a cell editor (or any other control editor). The change in focus actually causes any partial edit to be accepted, not canceled. This is similar to what was happening when I tried simply specifying an accelerator for Esc to active the editor. Since SWT does not know the difference between the control editor and any other view widget, it can't treat this case specially. It seems any control editor would also have to hook a traverse listener on ESC to set doit=false. Since we can't know the internal structure of views, and whether they use a control editor, I don't see how to solve this. Backing out of change pending recommendation from SWT.
*** This bug has been marked as a duplicate of 12360 ***
SN to discuss the nature of the fix with McQ.
Could you also comment on my questions above? Thanks
The fix is that if anybody hooks traverse and sets doit=false, the climb up the hierarchy is halted. In the case of the control editor, it sees the ESC and sets doit=false causing the climbing to stop before the fast view sees the key.
