Community
Participate
Working Groups
I am using two different handlers for the same command with different conditions, and functionality works fine, but there are few erros/warnings in the client log. I would like to clean up these erros in the log as customer is complaining about these errors. I tested with tracing option. Here is the output HANDLERS >>> Command('com.ui.open') has changed to 'com.ui.test1.actions.OpenAction' as its handler HANDLERS >>> resolveConflicts: eval: HandlerActivation(commandId=com.ui.open, handler=com.ui.test1.actions.OpenAction, expression=org.eclipse.core.internal.expressions.IterateExpression@9b3cba68,sourcePriority=1073741824) HANDLERS >>> resolveConflicts: eval: HandlerActivation(commandId=com.ui.open, handler=com.ui.test2.actions.OpenAction, expression=org.eclipse.core.internal.expressions.IterateExpression@39a07667,sourcePriority=1073741824) HANDLERS >>> Unresolved conflict detected for 'com.ui.open' HANDLERS >>> Command('com.ui.open') has changed to no handler I am using following handlers: 1. Activate com.ui.test1.actions.OpenAction when object is insatnceof BaseItem and Item1. <handler class="com.ui.test1.actions.OpenAction" commandId="com.ui.open"> <activeWhen> <iterate> <and> <instanceof value="BaseItem"> </instanceof> <instanceof value="Item1"> </instanceof> </and> </iterate> </activeWhen> </handler> 2. Activate com.ui.test2.actions.OpenAction when object is insatnce of BaseItem and Item2. <handler class="com.ui.test2.actions.OpenAction" commandId="com.ui.open"> <activeWhen> <iterate> <and> <instanceof value="BaseItem"> </instanceof> <instanceof value="Item2"> </instanceof> </and> </iterate> </activeWhen> </handler>
What is the case where they conflict? When using iterate (which defaults to "and") you should probably specify ifEmpty="false" Otherwise it is possible for both handlers to be "active" when the selection is empty. PW
I have the same problem(In reply to comment #1) > When using iterate (which defaults to "and") you should probably specify > ifEmpty="false" I do specify this "ifEmtpy", but the problem is the same. Example: TreeView with the following structure Root |-A |-B 1: DoubleClick on 'B' opens Editor-B. OK! 2: DoubleClick on 'A' opens Editor-A. OK! 3: Another DoubleClick on 'B' generates the failure org.eclipse.core.commands.NotHandledException: There is no handler to execute for command Desktop.Command.Edit.Entity at org.eclipse.core.commands.Command.executeWithChecks(Command.java:485) at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:178) at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:247) It is very interesting, I try to update the statusbar on selectionChanged, this works until step '3'. In this situation no event will be generated, neither SingleClick nor DoubleClick. The calling source-code: IHandlerService handlerService = (IHandlerService) PlatformUI.getWorkbench().getActiveWorkbenchWindow().getService(IHandlerService.class); // this doesn't work too //IHandlerService handlerService = (IHandlerService) PlatformUI.getWorkbench().getService(IHandlerService.class); try { handlerService.executeCommand( "Desktop.Command.Edit.Entity", null ); } catch (NotHandledException ex) { ex.printStackTrace(); } catch (Exception ex) { ex.printStackTrace(); } If I change the focus to the editor or to other windows applications, than everything is working, until step '3'. Similar failures: 54671
I solved my problem! Solution or the deeper description: Document 'A' has no editable field or button which might get the focus. Document 'B' sets the focus to an editable field. If Doc 'A' was opened, no focus was set and therefor a problem with trhe active workbench occured. by clicking on the treeview no new focus was set, so the opening of a Doc 'B' was done with the same parameters like Doc 'A'. In this case with the wrong command handler. Perhaps this might help you to find the real bug behind this!
(In reply to comment #3) > If Doc 'A' was opened, no focus was set and therefor a problem with trhe active > workbench occured. by clicking on the treeview no new focus was set, so the > opening of a Doc 'B' was done with the same parameters like Doc 'A'. In this > case with the wrong command handler. OK, it makes sense to me now. When we activate any part (view or editor) we call setFocus(*) on it and expect it to take focus. The act of taking focus fires SWT events (FocusOut/FocusIn/Activate) that are necessary for the workbench window to update its state. If you call setFocus() on one of your Controls (try a control in your editor, then a Composite if that doesn't work, and then a Label as a last resort) does it update correctly? PW
(In reply to comment #4) > (In reply to comment #3) > If you call setFocus() on one of your Controls (try a control in your editor, > then a Composite if that doesn't work, and then a Label as a last resort) does > it update correctly? I tried to make a readOnly input field editable and set the focus to it. And yes, now it works!
(In reply to comment #5) > I tried to make a readOnly input field editable and set the focus to it. > And yes, now it works! You mean you have a read-only field (like Text)? You can try a setFocus() on it without making it writable as well. PW
(In reply to comment #6) > (In reply to comment #5) > > I tried to make a readOnly input field editable and set the focus to it. > > And yes, now it works! > You mean you have a read-only field (like Text)? You can try a setFocus() on > it without making it writable as well. Yes i have a readOnly text-field and i have to make it writable. The setFocus on the readOnly field didn't solved the problem. cu Oliver
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.
