Community
Participate
Working Groups
Eclipse 3.2 Steps to reproduce: 1.) Have a Control inside the Trim-Area (e.g. Status Line) that is capable of taking Focus (e.g. a Text Field) 2.) Open an Editor and give it Focus 3.) Move Focus into the Text field in the Status Line Area Actual Results: The Editor is still indicating Focus and hitting a command like "Paste" is pasting into the Editor, although the Focus is inside the Text field. Suggestion: The workbench should intercept Activate-Events that occur outside of Views, as in this case in the Trim-Area and take care of updating the previous focussed View. Ben
I certainly agree that we have to do something to allow edit and other suchlike controls to work correctly when hosted in the trim, at least to the extent of getting the standard operations (cut/paste...) working. I'll take a look to see what's involved. We're looking into the command handling anyway so the timing is right...
That's great, thanks.
I have the same problem, once for the standard Copy/Paste commands, but also for a command that is bound to ENTER. I tried to set up a command context and activate it when the trim control gets focus (and deactivate it when it loses focus). This wouldn't help, though, because the editor's context has priority and there is no event that would cause the editor to deactivate its own context.
I'm going to have to defer this to M4 (which is when I'll be starting my work on the commands infrastructure).
Deferring in favor of getting the Commands story done...
Deferring to M6 and adding Paul so we can go over the proper way to integrate this (new Source type...).
I'm raising the severity as this problem results in critical usability issues in certain applications.
It doesn't cause a crash. PW
Paul and I are actively working on this...stay tuned.
We've already checked in the code (see bug 177806) for this. If you register your control with the new FocusService and provide appropriate handlers it should work now... Marking as fixed...
in I20070322-1800 With: <handler class="org.eclipse.ui.internal.handlers.WidgetMethodHandler:paste" commandId="org.eclipse.ui.edit.paste"> <activeWhen> <with variable="activeFocusControlId"> <equals value="z.ex.about.focusControl"/> </with> </activeWhen> </handler> <handler class="org.eclipse.ui.internal.handlers.WidgetMethodHandler:cut" commandId="org.eclipse.ui.edit.cut"> <activeWhen> <with variable="activeFocusControlId"> <equals value="z.ex.about.focusControl"/> </with> </activeWhen> </handler> <handler class="org.eclipse.ui.internal.handlers.WidgetMethodHandler:copy" commandId="org.eclipse.ui.edit.copy"> <activeWhen> <with variable="activeFocusControlId"> <equals value="z.ex.about.focusControl"/> </with> </activeWhen> </handler> <handler class="org.eclipse.ui.internal.handlers.SelectAllHandler" commandId="org.eclipse.ui.edit.selectAll"> <activeWhen> <with variable="activeFocusControlId"> <equals value="z.ex.about.focusControl"/> </with> </activeWhen> </handler>
Thanks for taking care of this. The copy/paste/... actions now work flawlessly in the trim control. However, I wonder if the following problem that I still encounter is solved with the new Command story, too (maybe I am doing something wrong): I have declared my own context, handler and keybinding to handle the CR in the trim. When the trim gets focus, I activate the context -- when it loses focus, I deactivate it. If there is an active editor that defines a keybinding/handler for CR, too, there is still a conflict. There are two different active contexts that try to handle CR. Shouldn't the trim have the higher priority in this case, too? (<activeWhen> is defined like for copy, paste etc.).
Patrick, you might want to open a separate defect regarding your issues with the keybinding issues; it's a spearate issue and defects that are 'Verified/Fixed tend to drop off of our radar...;-).
