Home » Eclipse Projects » Eclipse Platform » Using commands in a view toolbar
| | | |
| Re: Using commands in a view toolbar [message #660207 is a reply to message #660011] |
Thu, 17 March 2011 11:19   |
|
On 03/16/2011 10:39 AM, David Pérez wrote:
> Paul, do you think this is the best behaviour for toolbar-specific items?
>
> In order to execute a command in a toolbar view, you have to activate
> the view and then click the command.
Yes, that's the correct behaviour. You cannot act within a view (from a
UI point of view) without activating it. So acting within a view will
put the system in the correct state.
ex: View A contributes a refresh handler, View B contributes a refresh
handler. When a view contributes a handler, you only want that handler
active when the view is active.
If it makes sense for your command to be active all the time, then you
would use plugin.xml to contribute it. It would use the application
context to extract the active part (if that's a good behaviour) or get
the active window and find the part it cares about.
> I suppose, commands aren't used (or aren't registered with the IViewSite).
Right. Programmatically activating handlers within a view will restrict
those handlers to that view. Handlers that apply at the window level
are usually contributed through plugin.xml, as are most of the platform
handlers (if we can).
There is a simplification of enablement that's part of the architecture
of 3.x that I think can be improved (it is actually an attribute of each
global command instance). Right now everybody operates against the
global application state. That makes it hard to localize certain kinds
of information, like your view handler really only cares about the state
provided by your view.
In Eclipse 4, the view toolbar checks enablement by asking its view, as
opposed to in Eclipse 3.x where it goes to the global application state.
PW
--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Platform_Expression_Framework
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
| Re: Using commands in a view toolbar [message #661361 is a reply to message #660207] |
Thu, 24 March 2011 11:34 |
 David Pérez
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Finally, I have solved what I consider a problem. 
The solution is to use this class instead of a CommandContributionItem to populate the view items.
public class LocalHandlerContributionItem extends Comman dContributionItem {
protected IHandler handler;
public LocalHandlerContributionItem(CommandContribu tionItemParameter contributionParameters, IHandler handle r) {
super(contributionParameters);
this.handler = handler;
}
public boolean isEnabled() {
if (handler instanceof IHandler2) {
((IHandler2) handler).setEnabled(me nuService.getCurrentState());
}
return handler.isEnabled();
}
@Override
protected void handleWidgetSelection(Event event) {
Command cmd = command.getCommand();
IHandler oldHandler = cmd.getHandler();
cmd.setHandler(handler);
command.getCommand().setHandler(handler);
try {
super.handleWidgetSelection(event);
} finally {
cmd.setHandler(oldHandler);
}
}
}
You have to pass the handler that you have registered previously with IHandlerService#activateHandler()
The trick is to use the supplied handler, instead of the current handler of the command.
I hope this is useful for other people having the same problem like me.
This is the last problem I had to use commands everywhere, instead of actions.
David
| Paul Webster wrote on Thu, 17 March 2011 07:19 | On 03/16/2011 10:39 AM, David Pérez wrote:
> Paul, do you think this is the best behaviour for toolbar-specific items?
>
> In order to execute a command in a toolbar view, you have to activate
> the view and then click the command.
Yes, that's the correct behaviour. You cannot act within a view (from a
UI point of view) without activating it. So acting within a view will
put the system in the correct state.
ex: View A contributes a refresh handler, View B contributes a refresh
handler. When a view contributes a handler, you only want that handler
active when the view is active.
If it makes sense for your command to be active all the time, then you
would use plugin.xml to contribute it. It would use the application
context to extract the active part (if that's a good behaviour) or get
the active window and find the part it cares about.
> I suppose, commands aren't used (or aren't registered with the IViewSite).
Right. Programmatically activating handlers within a view will restrict
those handlers to that view. Handlers that apply at the window level
are usually contributed through plugin.xml, as are most of the platform
handlers (if we can).
There is a simplification of enablement that's part of the architecture
of 3.x that I think can be improved (it is actually an attribute of each
global command instance). Right now everybody operates against the
global application state. That makes it hard to localize certain kinds
of information, like your view handler really only cares about the state
provided by your view.
In Eclipse 4, the view toolbar checks enablement by asking its view, as
opposed to in Eclipse 3.x where it goes to the global application state.
PW
|
|
|
| |
| Re: Using commands in a view toolbar [message #662308 is a reply to message #661922] |
Wed, 30 March 2011 08:35 |
David Pérez
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Thanks Paul for your valuable advice.
I hope in e4 I won't need this kind of patches, otherwise, I'll redo my patches.
Here is an improved version, that handles correctly enabling expressions:
public class LocalHandlerContributionItem extends Comman dContributionItem {
protected IHandler handler;
protected IEvaluationService evalServ;
protected Expression expr;
protected boolean exprTrue = true;
protected IHandlerListener handlerListener = new IHandlerListener() {
@Override
public void handlerChanged(HandlerEvent h andlerEvent) {
update();
}
};
public LocalHandlerContributionItem(CommandContribu tionItemParameter params, IHandler handler, Expression expr) {
super(params);
this.handler = handler;
handler.addHandlerListener(handlerListener);
if (expr != null) {
this.expr = expr;
evalServ = SWTUtil.getService(para ms.serviceLocator, IEvaluationService.class);
evalServ.addEvaluationListener(expr, new IPropertyChangeListener() {
public void propertyChange (PropertyChangeEvent event) {
exprTrue = (Boolea n)event.getNewValue();
update();
}
}, "enabled");
}
}
@Override
public boolean isEnabled() {
if (!exprTrue) {
return false;
}
if (handler instanceof IHandler2) {
((IHandler2)handler).setEnabled(menu Service.getCurrentState());
}
return handler.isHandled() && han dler.isEnabled();
}
@Override
protected void handleWidgetSelection(Event event) {
Command cmd = command.getCommand();
IHandler oldHandler = cmd.getHandler();
cmd.setHandler(handler);
try {
super.handleWidgetSelection(event);
} finally {
cmd.setHandler(oldHandler);
}
}
@Override
public void dispose() {
if (handlerListener != null) {
handler.removeHandlerListener(handle rListener);
handlerListener = null;
}
super.dispose();
}
}
David
| Paul Webster wrote on Mon, 28 March 2011 10:16 | On 03/24/2011 07:35 AM, David Pérez wrote:
> Finally, I have solved what I consider a problem. The solution is to
> use this class instead of a CommandContributionItem to populate the view
> items.
>
Just remember you'll possibly run into problems with this in the 4.x SDK
as the handler will be chosen by the system and the method of
determining the state to use is also different.
PW
|
|
|
| | | |
Goto Forum:
Current Time: Sat Apr 27 01:09:22 GMT 2024
Powered by FUDForum. Page generated in 0.03391 seconds |
] 
Search
Help
Register
Login
Home
but.....
because I have first to activate a view in order to click a toolbar button, instead of clicking it directly.
