| Commands and default behavior: Save [message #489189] |
Thu, 01 October 2009 14:54  |
Eclipse User |
|
|
|
Despite having done a bunch of seemingly cool stuff with Commands (thanks to all who have asked and answered useful questions here), I'm not quite groking how to coax out "default" platform behavior.
Simple RCP app -- View, Editor, not much else interesting. I add a menu entry with commandId org.eclipse.ui.file.save. When I open an Editor, it is disabled (correctly, since the editor is not dirty). When I change anything in the Editor, I get the asterisk in the title bar indicating it is dirty -- but the Save command (on the toolbar and in the File menu) does not become enabled (nor does the Ctrl-S shortcut). I swear that when I first added this behavior weeks ago, it worked, but maybe I was imagining that. Or maybe there is some interaction with the other stuff that is blocking the correct behavior.
The obvious answer is I don't have a handler. But when I go to add one, I can't find any way to say "use the Save handler that already exists and handles this just fine already". FWIW, we're on 3.4. I didn't add a handler for org.eclipse.ui.help.aboutAction and my About box comes up fine.
I did find this comment in one of Lars (typically excellent) tutorials: "Standard commands sometimes map to actions which are contributed via ActionFactory in the class ApplicationActionBarAdvisor. If the ActionFactory returns an IAction you need to register this action. If not these commands are inactive in your menu.". Is this case one of those? If so, how can I tell? Where should I look next time in order to figure it out ahead of time rather than back into it?
Thanks...Millard
|
|
|
| Re: Commands and default behavior: Save [message #489198 is a reply to message #489189] |
Thu, 01 October 2009 15:44  |
| Eclipse User |
|
|
|
It seems this is one of those cases -- after adding the necessary create/register to ActionBarAdvisor, it all works again [Looking back, I incrementally tore down the Actions stuff and I must have had the makeAction stuff still in place while starting the Commands migration. When I deleted most of the stuff in makeActions(), thinking I didn't need it, it broke -- and I didn't notice quickly enough.]
So, one question remains: How can you tell when you need to do this? And a related question: Is this "legacy" behavior?
New question: I need to do some of this stuff in a plug-in that is not the application (call it the toolkit). Only the application level has an ApplicationActionBarAdvisor that gets called. What I've done for now is add a ToolkitActionBarAdvisor that the Application level calls during it's makeActions(). But that doesn't feel entirely cool. If a plug-in can contribute stuff that requires this sort of behavior, it shouldn't have to rely on the host to enable it, should it?
|
|
|
Powered by
FUDForum. Page generated in 0.04292 seconds
Home