如何使 Eclipse RCP 应用程序的键盘快捷键（加速器）在启动后立即工作？
我们的 Eclipse RCP 应用程序最初是在 3.1/3.2 时代构建的，一直在 3.2 上运行，直到我们最近切换到 3.6。它的 IApplication 通过 PlatformUI.createAndRunWorkbench(...) 运行。我们传递给该函数的 WorkbenchAdvisor 会覆盖 createWorkbenchWindowAdvisor(...) 以返回一个 WorkbenchWindowAdvisor，其 createActionBarAdvisor(...)< /code> 返回一个 ActionBarAdvisor。
这个 ActionBarAdvisor 的 makeActions(...) 创建并 register() 一堆 org.eclipse.jface.action。 Action，其中许多在其构造函数中执行诸如 setAccelerator(SWT.CTRL | 'O'); 之类的操作。 Action 随后安装在 ActionBarAdvisor 的 fillMenuBar(...) 和 fillCoolBar(...) 中代码>方法。
我们遇到的问题（现在我们使用的是 Eclipse RCP 3.6）是这些加速器在显示菜单之前似乎并不处于活动状态（即使除了再次关闭菜单之外没有采取任何操作）。
我们看到相关错误，但在理解如何应用其对我们的情况进行补救。我们认识到，我们“应该”使用命令、处理程序和键绑定，而不是 Action。但我们希望我们还不必走这条路。
如何才能让我们的加速器在应用程序启动后立即“上线”？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您不选择使用 oeui.bindings 扩展点，那么没有更好的方法。您应该只强制自己更新 menuManager，就像您在答案中所做的那样。
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.
正如 @Prakash 提到的，如果您想在 RCP 应用程序中保留该路径，则必须渲染所有主菜单才能看到加速器。
有一个部分升级路径可以让您走上命令的正确轨道，而无需立即强制完全切换。对于菜单中的每个操作，定义一个带有 id 的命令，并在 plugin.xml 中定义与所需快捷方式的绑定。然后，当您在 ActionBarAdvisor 中创建操作时，不要设置加速器。设置IAction.setActionDefinitionId(*)为命令id，可以调用register(action)；
然后您不再需要使用 menuManager.updateAll(true) 来急切地渲染所有主菜单。
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.
经过一番寻找和尝试后，尝试应用错误的建议，我们在
WorkbenchWindowAdvisor中添加了以下内容，这似乎已经达到了目的：我们不知道这与 Workbench 的设计期望的契合程度如何；可能有更好的方法。
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:We have no idea how well this fits with the Workbench's design expectations; there could be a better way.