Community
Participate
Working Groups
Hi, My editor presentation space consists of a number of widgets (StyledText, Trees, Tables etc). These widgets have context menus with Cut, Copy, Paste, SelectAll and Delete actions. I also need to make sure that when user selects same actions from Eclipse's main menu, my code is executed. I achive this by calling the following (this is a snippet from Copy action): When the action object is created: Action myCopyAction = new MyCopyAction(); actionBars.setGlobalActionHandler( ActionFactory.COPY.getId(), myCopyAction); And in the constructor: setId( ActionFactory.COPY.getId() ); setActionDefinitionId( IWorkbenchActionDefinitionIds.COPY ); activateHandler( true ); I also need hotkeys (such as Ctrl+C) to work, so I use HandlerService and ActionHandler (from org.eclipse.jface.commands) to associate my action and Eclipse's command, like this: void activateHandler( boolean active ) { if( m_testEditor == null ) { return; } if( active ){ IHandlerService handlerServer = (IHandlerService)getEditorPart().getEditorSite().getService(IHandlerService.class); final String id = getActionDefinitionId(); ActionHandler a = new ActionHandler( this ); m_handlerActivation = handlerServer.activateHandler( id, a); } else { if( m_handlerActivation != null ){ m_handlerActivation.getHandlerService().deactivateHandler(m_handlerActivation); m_handlerActivation = null; } } } I have the following problem: When there are two editors opened at the same time side by side (both of them create and setup actions as descibed above), global actions (including hotkeys) are taken from one of them (usually the second one that becomes active) and never from the other. When I activate the first editor, going to the main menu and selecting an action, results in the code being executed inside the second, now inactive editor. Of course, when I execute the same action from the context menu, it works alright, because I am construcing popup menus myself. But Eclipse is confused. When there is only one editor open, hotkeys usually do not work at all (sometimes they do after lots of switching between multiple views and editors). Please tell me what am I doing wrong or what is missing? There are no errors or exceptions of any kind.
This issue is regarded as critical in our product
This counts as loss of functionality. PW
That's why I thought it was critical :-)
Alex, actionBars.setGlobalActionHandler( ActionFactory.COPY.getId(), myCopyAction); will activate your action for your editor. You don't need to activate it your constructor. AFAIK, you also have to target the actions at your editor. Check out how TextEditorActionContributor in org.eclipse.ui.editors uses this method in setActiveEditor(IEditorPart) (technically, doSetActiveEditor(*)) or BasicJavaEditorActionContributor. in setActiveEditor(IEditorPart) they update the action with the new editor having called setGlobalActionHandler(*) in the init(*) method. PW
Does this mean that there supposed to be exactly one instance of each (global) action per editor type? And that each such instance should react not only to the selection change, but also track editors activations? This is not at all obvious from any documentation I have read. As for the constructor, I call my method 'activateHandler' from it. I need to do this in order to make sure the hotkeys (mnemonics) work. Sorry if I have not made this clear enough. The 'setGlobalActionhandler' method is called by outside code when the actionas are created.
I have re-written my code so that there is just one instance of each type of action. Each action gets updated when either the selection within current editor changes, or when another editor becomes active. The end result -- Hotkeys work in unpredictable manner. Usually it requires second editor to be opended and activated for hotkeys to begin to work. Later on it hotkeys stop working again. However, the actions themselves become enabled and disabled in a proper way and always refer to the correct selection.
There is still an open bug 137091 that effects proper operation of keybindings set using setGlobalActionHandler(*). You might now be hitting that. PW
Looks very similar. Do you know what the plans are for fixing this problem?
I have noticed that in most cases the LegacyHandlerWrapper::isEnabled() returns false, which prevents hotkeys to work. public final boolean isEnabled() { final Object enabled = handler.getAttributeValuesByName().get( ILegacyAttributeNames.ENABLED); if (enabled instanceof Boolean) { return ((Boolean) enabled).booleanValue(); } return true; } The 'isEnabled' method is called from Command.executeWithChecks(ExecutionEvent). if (!isEnabled()) { final NotEnabledException exception = new NotEnabledException( "Trying to execute a disabled command"); //$NON-NLS-1$ fireNotEnabled(exception); throw exception; } The Command->handler(LegacyActionHandler)->handler(ActionHandler)->action is not my action (registered via setGlobalActionHandler), but some other action (which is in the disabled state). 'fireNotEnabled' does not actually log anything because the DEBUG and DEBUG_VERBOSE are both false. How do I set them to true? Hope this info helps.
I have mention in my report that in the constructors of my edit actions I make the following call: For my copy action: setId( ActionFactory.COPY.getId() ); I think that creating actions with factory IDs is wrong and that I have to use unique IDs. Is this correct?
(In reply to comment #10) > I have mention in my report that in the constructors of my edit actions I make > the following call: > > For my copy action: > setId( ActionFactory.COPY.getId() ); yes, it's a good idea to use your unique action IDs for your specific actions. But it is correct to use: setActionDefinitionId( IWorkbenchActionDefinitionIds.COPY ); and actionBars.setGlobalActionHandler( ActionFactory.COPY.getId(), myCopyAction); PW
(In reply to comment #9) > > 'fireNotEnabled' does not actually log anything because the DEBUG and > DEBUG_VERBOSE are both false. How do I set them to true? > Sorry, Alex, http://wiki.eclipse.org/index.php/Platform_Command_Framework#Tracing_Option You would probably want to add a commands tracing option to the file mentioned in the above link: org.eclipse.ui/trace/commands=true You can turn some of the others off if you want. For evaluating if CTRL+C is calling the correct handler, you probably want handlers, keybindings, and commands. PW
(In reply to comment #0) > When I activate the first editor, going to the main menu > and selecting an action, results in the code being executed inside the second, > now inactive editor. I do have exactly the same problem using retagret undo/redo-actions in my graphical Editor which is based on GEF. As this bug is quite old. Has there allready been a fix or workaround for this? I'm using Eclipse 3.2.2 Build id: M20070212-1330 Thanks Alex Haag
(In reply to comment #13) > > I do have exactly the same problem using retagret undo/redo-actions in my > graphical Editor which is based on GEF. > > As this bug is quite old. Has there allready been a fix or workaround for this? Quite a lot of the missing Command Framework was implemented in 3.3, but to find out if your particular problem has been sovled you would have to try on 3.3.1 PW
(In reply to comment #14) > Quite a lot of the missing Command Framework was implemented in 3.3, but to > find out if your particular problem has been sovled you would have to try on > 3.3.1 Sorry, but after downloading the newest versions (Eclipse 3.3.1.1, GEF 3.2.101, EMF 2.3.0) the problem is still there. Greets Alex Haag
Alex, could you please attach a debug trace of the problem as per comment #12 Then either annotate it or provide the usecase steps (open editor one, open editor two, COPY, PASTE, UNDO, etc). PW
Alex, are you seeing bug 173361 ? This seems to have been caused by bug 162964 and fixed by 200424 but not until 3.4M3 (which should come out the end of this week). PW
Created attachment 81567 [details] Debug trace of application Hi, here is the debugtrace of my application. The actions made by the user were: - start of application - open editor 1 via doubleclick (editor 1 will be selected thereafter) - do move-action on open editor 1 - switch to filenavigator to open second editor - open editor 2 via doubleclick (editor 2 will be selected thereafter) - select editor 1 - select special view for editor (this view has allways the commandstack of the current active editor and provides standard GEF undo/redo-actions using this commandstack; this time -- commandstack of editor 1!) - select editor 1 - select editor 2 - select special view for editor (this time the view has the commandstack of editor 2!) - shutdown of application.
Created attachment 81576 [details] Debugtrace of application run with eclipse 3.3.1 Sorry I mixed the debug-traces. The one posted earlier has been from eclipse 3.2.2 This one here is logged while running the application using eclipse 3.3.1 Greets Alex
Not sure which Alex you mean, but since I have submitted this defect more than a year ago, I have put several workarounds in my code to make it work. I will not be able to recreate environment I had back then in order to reproduce this defect.
(In reply to comment #20) > Not sure which Alex you mean, but since I have submitted this defect more than Sorry, Alex, I've beem hassling Alexander Haag :-) PW
(In reply to comment #19) > Created an attachment (id=81576) [details] > Debugtrace of application run with eclipse 3.3.1 Thank you for the stack traces, Alex. Alex, are you seeing bug 173361 ? PW
(In reply to comment #22) > Alex, are you seeing bug 173361 ? Thanks Paul, yes I checked this bug. But while my problem is with GEF undo/redo, bug 173361 is about GMF. I'm not quite sure but I think GMF provides its own undo/redo actions and does not use the ones from GEF. I'll follow up that matter after my two days break! As for now if there is anything I can provide, please let me know. Greets Alex Haag
Updated as per http://wiki.eclipse.org/Platform_UI/Bug_Triage PW
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.
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.
