I've implemented org.eclipse.ui.edit.delete command handler and I want to invoke it with Edit/Delete main menu item.
As "delete" action is a retargetable action invoking another defined in the context of each edit, editor is usually configured with IActionBars.setGlobalAction(String id, IAction action) where id = "delete" and action is a custom action to be invoked by a retargetable one.
I can see following options:
Create an action that would delegate its execution and state change monitoring to a command
convert convert existing command into an argument for setGlobalAction, probably copying org.eclipse.ui.internal.actions.CommandAction approach.
Remove an existing action from the main menu and insert command contribution item instead
Both ways look too complex/dirty. Am I missing something? Can I use a command instead of action?
EDIT:
It seems that main menu is implemented not with IAction, but with CommandContributionItem. The default command handler invokes CommandAction which in turn queries RetargetAction. "Better" handler for the command can override this behavior.
While I can provide a handler for delete command now, the question is still actual as calling a command from GUI (for example by clicking on a button) is useful and custom commands are not so easy to call (they have no default key bindings or retargetable actions).
Related
When adding a new item to a toolbar, you are given the option to choose Handled ToolItem, Direct ToolItem and Toolcontrol:
What is the difference between these three choices? I can't find the documentation for these anywhere.
'Handled' items are used when you have defined a command id and one or more handlers for the command. In the HandledToolItem you specify the id of the command that is to be executed.
'Direct' items are used when you just want to specify a Java class to be executed without using a command id and separate handler.
Toolcontrol is used when you want to write you own code for the control in the tool bar (something like a Combo for example).
I need CTRL+N to invoke the default behavior, that is to create a new record without invoking my NewButton.
NewRecordAction property is not filled out, the shortcut does nothing, seems to be disabled.
The DataSource on the form allows create, I can create through my NewButton MenuItemButton.
I seem to have lost it's default behavior somehow, what could cause that?
Ctrl-N does not do anything, because the NewRecordAction is not filled out and because there is not a command button with New in the Command property.
I assume you have used "Create form from template" or have copied from the SysBPStyle_TransactionDetails form (same thing). This form contains a botton NewButton which is ment to call a creation form, like the SalesCreateOrder form.
You have two options:
Fill out the NewRecordAction with the control name of your create menu item. This should be mandatory in list pages.
Delete the NewButton, then create a new command button with New in the Command property. Also remember to assign a value to the DataSource property on the control or a containing node.
I personally prefer the second option (maybe combined with a setFocus call) because a create form is then not needed and there is only one form for you to maintain and the user to learn.
I want to use copy and paste within my own view. Therefore I defined commands with a special context and activated it during the creation of the view.
The problem I'm now facing is that copy and paste is workin within my view but no longer within the normal eclipse world.
The context has a parent id into org.eclipse.ui.window.
Any hints how to seperate these contexs right so corresponding action is called at the right time.
I also turned on the key bind tracing within the debug options of org.eclipse.ui.
basic idea: How to override an existing key binding?
http://rcpexperiments.blogspot.de/2009/07/commands-key-bindings-and-contexts-in.html
key tracing: http://eclipsesource.com/blogs/2009/07/08/tip-tracing-keybindings-in-rcp/
You shouldn't need to use a context. You just provide an action handler for the global copy / paste actions:
IActionBars actionBars = getViewSite().getActionBars();
actionBars.setGlobalActionHandler(ActionFactory.COPY.getId(), copyAction);
actionBars.setGlobalActionHandler(ActionFactory.PASTE.getId(), pasteAction);
I'm working on a way to maximise an EditorPart in my Eclipse-based RCP app to be absolutely full-screen, no trim, no menu, and so on. Actually, it's a GEF Editor. It's a bit of a hack, but it kind of works:
GraphicalViewer viewer = (GraphicalViewer)getWorkbenchPart().getAdapter(GraphicalViewer.class);
Control control = viewer.getControl();
Composite oldParent = control.getParent();
Shell shell = new Shell(SWT.APPLICATION_MODAL);
shell.setFullScreen(true);
shell.setMaximized(true);
// Some code here to listen to Esc key to dispose Shell and return...
shell.setLayout(new FillLayout());
control.setParent(shell);
shell.open();
Basically it sets the parent of the GraphicalViewer control to the newly created, maximised Shell. Pressing escape will return the control to it's original parent (code not shown for brevity).
The only thing that doesn't work is receiving global key presses (Del, Ctrl+Z, Ctrl+A) the ones that are declared for the Workbench and forwarded to the EditorPart. Is there any way I can hook into these or redirect them from the EditorPart to forward them on to the GraphicalViewer?
Thanks in advance
The short answer is you can't do that. Once you re-parent that composite out of the workbench window, it's totally busted. The system won't correctly deal with the part, as events (like activation, focus, setBounds(*)) aren't being processed.
The only supported way would be to open a new Workbench window with a perspective that only contained the editor area, and extending your org.eclipse.ui.application.WorkbenchWindowAdvisor.createWindowContents(Shell) method for that window+perspective combination to hide all of the trim you don't want, using org.eclipse.ui.application.IWorkbenchWindowConfigurer.
ex, in MyWorkbenchWindowAdvisor:
public void createWindowContents(Shell shell) {
if (isCreatingSpecialPerspective()) {
final IWorkbenchWindowConfigurer config = getWindowConfigurer();
config.setShowCoolBar(false);
config.setShowFastViewBars(false);
config.setShowMenuBar(false);
config.setShowPerspectiveBar(false);
config.setShowProgressIndicator(false);
config.setShowStatusLine(false);
}
super.createWindowContents(shell);
}
Also check out http://code.google.com/p/eclipse-fullscreen/ which has EPLed code in it concerned with running an RCP program with fullscreen support.
My suggestion is to try to approach this problem from another angle. Instead of listening for keystrokes in your code and acting upon them, define your own key binding scheme and then create commands and make them use this scheme. This would mean that you no longer have to listen for the key strokes in your code, but instead do whatever needs to be done through commands executed by these key strokes.
I'm currently struggling with the following Eclipse RCP commands:
org.eclipse.ui.edit.cut
org.eclipse.ui.edit.copy
org.eclipse.ui.edit.paste
I'm using them as command contributions in the toolbar, but the UIElements (toolbar items) are not updated when the 'handled' state of those commands changes.
For testing I used a polling mechanism to verify that the state of those commands really changes depending on the currently focussed element, and I found out that the handler remains the same but the handler's 'handled' state changes properly, causing the commands 'handled' state to also change properly.
The only problem is, that neither one of those state changes causes a notification (neither on the command's ICommandListener, nor on the handler's IHandlerListener), so the UIElements won't get updated.
Here's some testing code to observe the states of a Command:
ICommandService commandService = (ICommandService) PlatformUI.getWorkbench().getService(ICommandService.class);
final String commandId="org.eclipse.ui.edit.copy";
Command command = commandService.getCommand(commandId);
command.addCommandListener(new ICommandListener() {
public void commandChanged (CommandEvent commandEvent) {
System.out.println(">> Command changed: " + commandId);
}
});
Am I missing something, or is this an bug in the cut/copy/paste handler implementations?
Any insights?
EDIT:
The commands are enabled all the time, and the handler is never exchanged, only the handler's 'handled' state (and thus also the commmand's 'handled' state) changes depending on which ui element has the focus. There is however no notification when this state changes.
This results in the toolbar buttons always being enabled, and pressing them will cause a org.eclipse.core.commands.NotHandledException: There is no handler to execute for command.
The handler which is registered for the cut/copy/paste commands is org.eclipse.ui.internal.handlers.WidgetMethodHandler. This handler checks if a given method is declared on the current display's focus control. When executed, that handler will invoke the method using reflection.
Snippet from WidgetMethodHandler:
public final boolean isHandled() {
return getMethodToExecute() != null;
}
The getMethodToExecute() will locate the current focus control using Display.getCurrent().getFocusControl(), and then check if the given trigger method is declared on it.
Widgets such as org.eclipse.swt.widgets.Text have cut(), copy() and paste() methods, so when the focus is on such a widget, the handler will return 'true' for isHandled().
This handler is however not aware when the current focus control changes (I think there isn't even a way to observe this on the Display), and thus can't notify about changes on its dynamic 'isHandled' state.
This results in the cut/copy/paste commands being fine for popup menus, but they're quite problematic when used in toolbars, as their UI elements can't be updated properly when the handler does no notifications.
This leaves me with either not using those commands in the toolbar, or having a polling mechansim to update the ui elements (which is also bad and error prone). :-(
Your problem is that you need to register a handler for anything that is not a text because Eclipse needs to know how to copy the currently selected "something" to the clipboard. That's what a handler does. This article in the Eclipse wiki will get you started how to create and register a handler.
I could be wrong, but the source of the problem is that the handler is always enabled.
See Platform Plug-in Developer Guide > Programmer's Guide > Plugging into the workbench > Basic workbench extension points using commands > Handlers.
The <activeWhen/> expressions in the
plugin.xml and programmatic core
expressions are used to help determine
the scope of a handlers activation.
For example, a specific window, a
specific Shell, an active part type or
active part.
<extension
point="org.eclipse.ui.handlers">
...
<handler
class="org.eclipse.ui.examples.contributions.view.SwapInfoHandler"
commandId="org.eclipse.ui.examples.contributions.view.swap">
<activeWhen>
<reference
definitionId="org.eclipse.ui.examples.contributions.view.inView">
</reference>
</activeWhen>
<enabledWhen>
<count
value="2">
</count>
</enabledWhen>
</handler>
...