Community
Participate
Working Groups
Build Identifier: I20110518-2200 it might be same as this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=323706 that is, if that one gets fixed maybe this one will too. But check this first: Basically Ctrl+A should select the text in the current text area but it doesn't, instead something unfocused in another window gets selected. Reproducible: Always Steps to Reproduce: 1. get a detached Problems view, ie. Window->Show View->Problems, right click on its title tab and Detached (ok this doesn't exist in e4? it's only Close, then I don't know how you detach it in e4 but since I already used settings and workspace from a 3.7 eclipse it remained detached) 2. make sure Errors and/or Warnings have children and they are expanded (at least 1 child should be visible, else if none expanded this won't work) 3. click inside the editor (inside a java file) OR click on a file in Package Explorer (Ctrl+A will have effect here) 4. click in Problems view directly on any child (or even the parent) 5. now click on Window->Preferences, you should be focused on the Filter text , you can enter some text(preferably) and/or just press Ctrl+A there, this won't select the entered text, this will in fact apply Ctrl+A in the editor, or in package explorer (depending which one was last focused before you clicked on a child in Problems View)
(In reply to comment #0) > 1. get a detached Problems view, ie. Window->Show View->Problems, right click > on its title tab and Detached (ok this doesn't exist in e4? it's only Close, > then I don't know how you detach it in e4 but since I already used settings and > workspace from a 3.7 eclipse it remained detached) Right now you'd have to resize your main window so it doesn't take up all the space and then click and drag the part outside the main window's area to detach it.
this also happens (in e4) when you activate the Quick Access ie. Ctrl+3 or just click on it, then type something(or not) and press Ctrl+A, it selects all code in my editor window (in a .java file) assuming of course that was the last one focused
more importantly, this also happens in the Commit Changes window of Team->Commit for git, ie. shift+delete for cut (which doesn't cut the text, only copies it) and shift+insert which will paste that text as new snippet (since my previous focused window was package explorer and the project root on which I clicked Team->Commit). Workaround is LMB click the Commit Message edit area and it works as expected
In 3.x we had to provide extra global source providers to support attaching handler to a trim control so that it could override the default workbench behaviour. See bug 177806 and bug 154268 In Eclipse 4 the architecturally correct solution would look like creating an IEclipseContext for that control and making it the active child of the Window context while that control is active. But that effects which handlers are enabled/disabled, what is the active part, and I'm not sure what that does to the available commands listed in the quick assist dropdown. PW
Created attachment 196998 [details] Option 1 - search field has a context v01 The search field gets its own context. It's activated when the text field gets focus. It provides handlers for the cut/copy/paste/select all This needs to be refined a little to handle all different SWT event combinations. PW
Created attachment 197000 [details] Option 2 - search field uses the Focus service v01 This uses the focus service and a handler expression to track the focus control. It is 3.x API, and it does not work. PW
Created attachment 197011 [details] Option 2 - search field uses the Focus service v02a Option 2 that works. Uses the IFocusService API. Fixes a bug in the handler lookup function in the legacy handler service bridge. PW
Remy, can you have a look at Option 2? PW
(In reply to comment #8) > Remy, can you have a look at Option 2? Patch looks okay. 'Home' and 'End' does nothing if your active part is a text editor though.
(In reply to comment #9) > 'Home' and 'End' does nothing if your active part is a text > editor though. Since this is not a regression, let's get the patch in for now to fix Ctrl+A at least.
Released to HEAD PW
Verified in I20110604-2201 Remy, for me the home/end keys work as long as the Quick Access doesn't have focus...
