I have a TPopupMenu with several buttons I would like to be activated via shortcuts. I have assigned them various shortcuts using the ShortCut property of the TPopupMenu class but they do not trigger the associated event when I use them. I seem to remember reading once that this functionality does not work for MDI applications - is this the case and, if so, what is the best way to overcome it?
Related
I face an issue regarding keyboard shortcuts using JFace IAction and setAccelerator(). My sample code:
menuAction.setAccelerator(SWT.CTRL | 'A');
The keyboard shortcut CtrlL+A is not recognised within my application.
To my knowledge, the accelerator property of an IAction only carries the information which key shortcut should be used.
The actual implementation that captures key shortcuts and executes matching actions is not part of JFace or at least not active by default. Some bits and pieces that are part of Platform/UI make it work in the workbench.
To see what is actually needed to make accelerators work in a standalone JFace application, you should follow the call to ExternalActionManager.ICallback::isAcceleratorInUse() in ActionContributionItem ~ line 825.
If this doesn't lead to a solution, you can still add a display filter to invoke the respective actions for a key shortcut (see also SWT Actions with Keyboard Shortcuts... without having to add them to the menu).
Don't forget to add this action menuAction to your menu manager and after applying all you stuffs you must to update the menu manager. Call updateAll(true) method on your menu manager. This update is required because the menu manager didn't notice your accelerator assignment yet!
Is it possible with some program to to send an OnClick Event eg: MenuNewClick (File New) or others.
I have an application that has no Keyboard shortcuts.
When I use a Resource Editor I can see the Delphi Forms for each OnClick Event I need.
I would just like to be able to send these OnClick Events with Keyboard Shortcuts into the running exe.
Have used apps like Darker's Enabler, EDA Preview that allow you to modify the layout of a running exe.
Possible ?
Even this forum has options "Keyboard shortcuts
Enable keyboard shortcuts (when enabled, press ? for help)"
Thanks.
If the application is indeed made with Delphi and if it uses default TMainMenu component you could modify the RCData in which the .dfm is stored (this data alows you to view the form and its properties with programs like PE Exporer and similar) in a way that you change the AutoHotkeys property of TMainMenu to maAutomatic and then change ShortCut property of each menu item to contain proper keyboard shortcut.
If you have access to Delphi I recomend you first make an example application which will have all available shourctuts implemented so you could comparison the RCData between these two applications and made necessary changes.
NOTE: What I'm suggesting will require editing the EXE resource data so make sure you are working on a copy of the exe and not on the real one so you don't break your application.
I know that I can implement multiple undo using the TextUndo widget. But that doesn't do the redo function.
How can I implement both multiple undo and multiple redo?
The text widget supports a full undo/redo functionality. You just have to turn it on; since not all uses of text want that sort of thing, it's off by default. To turn it on, you just need to set the boolean -undo widget option to true. It's as simple as that (though the way you write it might be a little different in languages other than Tcl, e.g., it's undo in Tkinter).
However, PerlTk seems to make a confused mess of it all. For some reason, the Tk::Text widget doesn't support undo/redo (Why? The machinery is in there, poking through.) and the Tk::TextUndo widget doesn't have the redo capability exposed (Why on earth would that be omitted?) These are all limitations in PerlTk, not Tk itself. In that case, your best bet might be the Tk::Text::SuperText class, though to me that's very odd as it's just doing what I consider to be core Tk functionality.
Or maybe it's just the CPAN documentation that's out of date.
Problem is that the '' binding is assigned twice, for the virtual event '<>' (to implement emacs-like pasting) and to the virtual event '<>'. A normal Tk::Text does not have the undo functionality, so having the C-y binding here makes sense. Unfortunately this binding clashes when using a Tk::TextUndo.
You have the following possibilities:
use the other bindings for Redo (e.g. the F12 binding, see Tk::MainWindow source code for a complete list, or the "Redo" entry in the popup menu)
remove the C-y binding for <<Paste>> globally, e.g. by using:
$mw->eventDelete('<<Paste>>', '<Control-Key-y>');
I am not sure how this can be resolved best in the Perl/Tk source itself. Simplest would be to remove the emacs key binding for '<>' here, but then emacs users could be unhappy. I am open to suggestions...
In our project at work, they have written one plug-in for eclipse helios. They have used the
objectContribution for adding the popups and written respective action classes for them.
I am trying to add the shortcut key for one of the popup menu item in project explorer.
But I read here http://www.eclipse.org/forums/index.php/mv/tree/172398/#page_top that there is no way to call key bindings from objectContribution and need to migrate it to handlers/commands.
Is there any other way to bind keys to popups instead of migrate them to handlers?
Thanks in advance!!
No, objectContributions cannot accept keybindings. From legacy action extension points, only actionSets accept keybindings correctly.
The other option available (as mentioned) is to provide a handler for the command you want. The handler won't interfere with the objectContribution behaviour (the objectContribution action delegate class will still be called directly from the menu item, the handler would be called when using a keybinding).
PW
Our Eclipse RCP application was originally built in the 3.1/3.2 era and was running on 3.2 until we switched to 3.6 recently. Its IApplication runs via PlatformUI.createAndRunWorkbench(...). The WorkbenchAdvisor we pass to that function overridescreateWorkbenchWindowAdvisor(...) to return a WorkbenchWindowAdvisor whose createActionBarAdvisor(...) returns an ActionBarAdvisor.
This ActionBarAdvisor's makeActions(...) creates and register()s a bunch of org.eclipse.jface.action.Actions, many of which do things like setAccelerator(SWT.CTRL | 'O'); in their constructors. The Actions are subsequently installed in the ActionBarAdvisor's fillMenuBar(...) and fillCoolBar(...) methods.
The problem we are having (now that we are on Eclipse RCP 3.6) is that these accelerators don't seem to be active until their menus are shown (even if no action is taken besides closing the menu again).
We see a relevant bug but are having some difficulty understanding how to apply its remedy to our situation. We recognize that instead of Actions we "ought" to be using commands, handlers, and key bindings. But we're hoping we don't have to go down that path just yet.
How can we make our accelerators "live" as soon as the application starts up?
If you don't choose to use o.e.ui.bindings extension point, then there isn't a better way. You should only force update the menuManager yourself as you have done in your answer.
As #Prakash mentioned, if you want to keep down that path in your RCP app you must render all of the main menus to see your accelerators.
There is a partial upgrade path that will get you on the right track to commands without forcing a complete switch over right away. For each action in your menu, define a command with an id and define a binding to the shortcut you want in your plugin.xml. Then, when you create the action in your ActionBarAdvisor, don't set the accelerator. Set the IAction.setActionDefinitionId(*) to the command id, can call register(action);
Then you no longer need to use menuManager.updateAll(true) to eagerly render all of your main menu.
After hunting around and experimenting a bit trying to apply the advice from the bug, we added the following to our WorkbenchWindowAdvisor, which seems to have done the trick:
#Override
public void postWindowCreate() {
getWindowConfigurer().getActionBarConfigurer().getMenuManager().updateAll(true);
}
We have no idea how well this fits with the Workbench's design expectations; there could be a better way.