Eclipse Community Forums: GEF » Testing and setting workbench button states

Home » Eclipse Projects » GEF » Testing and setting workbench button states(How to access and manipulate toggle-buttons)

Show: Today's Messages :: Show Polls :: Message Navigator

Testing and setting workbench button states [message #631628]

Fri, 08 October 2010 09:07

Chris

Messages: 44
Registered: April 2010

Member

Hi,

This is probably a simple one, but Google just buries me under piles of useless information, when I try to search for "Eclipse workbench" and related terms.

For an Editor I've put a button into the toolbar of the workbench, that toggles the view of the Editor. I'd like to be able to set its state from within the EditPart of my Diagram when switching tabs, to sync the current view state with the button. Also for some policies it would be really neat to access the state of the button, so they could adapt their behavior accordingly.

Regards,
Chris

Report message to a moderator

Re: Testing and setting workbench button states [message #631825 is a reply to message #631628]

Fri, 08 October 2010 23:20

rex

Messages: 9
Registered: September 2010

Junior Member

I think you are asking: how does an EditPart access an IAction which backs a workbench button?

Typically all actions are stored in the GraphicalEditor. You can locate an action by id in your subclass of GraphicalEditor by calling GraphicalEditor.getActionRegistry().getAction(id).

According to existing GEF chain of access, your EditPart can get your subclass of GraphicalEditor by calling: (I am assuming you are using DefaultEditDomain)

(yourGraphicalEditor)((DefaultEditDomain)getViewer ().getEditDomain ()).getEditorPart()

Actaully you can give your EditPart a reference to your GraphicalEditor. This needs a little bit help from your EditPartFactory. When you create your EditPartFactory in your GraphicalEditor, pass the reference to the EditPartFactory. Now the factory is able to pass the reference when creating your EditPart. As a result, you can access GraphicalEditor directly from EditPart.

Report message to a moderator

Re: Testing and setting workbench button states [message #632248 is a reply to message #631825]

Tue, 12 October 2010 09:37

Chris

Messages: 44
Registered: April 2010

Member

I used a Handler extending org.ecplipse.ui.commands. I didn't hook it up in code anywhere. The Handler fetches the Editor in its execute method by

	public Object execute(ExecutionEvent event)
			throws org.eclipse.core.commands.ExecutionException {
		 Command command = event.getCommand();
		 boolean oldValue = HandlerUtil.toggleCommandState(command);
		 
		 IEditorPart editor = HandlerUtil.getActiveEditor(event);
		 if(editor instanceof <myEditorClass>) {
			// send toggle message to Editor
		 }
		 
		 return null; 
	}

So accessing the ActionRegistry won't help me, right?

Should I replace the Handler/Command thingy with an IAction implementation? I ran into some problems with the Handler/Command solution before. I had read, that it would be the new/cool thing to do, and wanted to adopt that paradigm. But might it be the case, that the IAction support is still more stable/sophisticated?

Regards,
Chris

Report message to a moderator

Re: Testing and setting workbench button states [message #632696 is a reply to message #632248]

Wed, 13 October 2010 22:42

rex

Messages: 9
Registered: September 2010

Junior Member

Okay, now I understand your question. You were right. In general, the commands API is preferred over the actions API. According to the book Eclipse Plug-ins (Third Edition) at page 215:

Quote:

Commands and actions are two different APIs for accomplishing the same thing: declaring the implementing functions that manifest as menu items and toolbar buttons. The actions API has been around since before Eclipse 3.0, while the commands API has only just solidified as of Eclipse 3.3 with small refinements in Eclipse 3.4. It appears that at some point the actions API will be deprecated, moved into a compatibility layer and in the future removed, but much of the Eclipse tooling still makes extensive use of the actions API, not to mention third party tools and IDEs built on top of the Eclipse infrastructure.

However GEF has already made some decisions for us, and has done a lot of integration work between actions and GEF commands. For example, your action class, a subclass of GEF WorkbenchPartAction, will have access to your editor class and your GEF command class. No need to say those already defined relationship between many GEF classes in terms of storage and reference as I described in my last post.

I would suggest you to go with GEF design.

Report message to a moderator