Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » Programmatic handler enablement
Programmatic handler enablement [message #539842] Mon, 14 June 2010 01:29 Go to next message
Miles Parker is currently offline Miles Parker
Messages: 1340
Registered: July 2009
Senior Member
Hi all,

Is there really no way to have a handler use a programmatic enablement in all cases? i.e. all I want to do is ensure that on a given selection, my toolbar buttons, etc.. are immediately updated based on that selection. Instead, users have to click on a different view and then return to that view to enable state.

I've had a look at:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=171079
and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=179582

which make me think that this hasn't been addressed. I haven't been able to get the test case in comment 8 of bug 171079 to work reliably or perhaps it doesn't support what I want to do either.

Is there an accepted general approach for accomplishing this? Otherwise my only decent option is to leave the toolbars available in all cases and simply ignore user input which of course isn't very good from a usability POV either.

thanks,

Miles
Re: Programmatic handler enablement [message #539848 is a reply to message #539842] Mon, 14 June 2010 05:35 Go to previous messageGo to next message
Prakash G.R. is currently offline Prakash G.R.
Messages: 621
Registered: July 2009
Senior Member
On 14/06/10 6:59 AM, Miles Parker wrote:
> Hi all,
>
> Is there really no way to have a handler use a programmatic enablement
> in all cases? i.e. all I want to do is ensure that on a given selection,
> my toolbar buttons, etc.. are immediately updated based on that
> selection. Instead, users have to click on a different view and then
> return to that view to enable state.

You can even do this thru declarative enablement on handlers. See:
http://blog.eclipse-tips.com/2009/01/commands-part-2-selecti on-and.html

--
- Prakash
Platform UI Team, IBM

www.eclipse-tips.com
Re: Programmatic handler enablement [message #539975 is a reply to message #539842] Mon, 14 June 2010 13:37 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Could you open a bug with a simplified example of what you are trying to
do? I took the hello world command plugin and modified it to use an
enabledWhen and added it to the problems view:
<enabledWhen>
<iterate operator="and">
<instanceof value="org.eclipse.core.resources.IFile"/>
</iterate>
</enabledWhen>

and:

<menuContribution
locationURI="toolbar:org.eclipse.ui.views.ProblemView?after=additions ">
<command commandId="z.ex.hello.cmd.commands.sampleCommand"
icon="icons/sample.gif"
tooltip="Say hello world"
id="z.ex.hello.cmd.toolbars.sampleCommand"/>
</menuContribution>

As I click on IFiles in the Package Explorer, the item in the Problems
toolbar enables and disabled. Of course, as soon as I click in the
Problems view it goes disabled, since the problems view doesn't have
IFiles in it. To pick up .java files in the Package Explorer, use adapt
instead of instanceof.

What variables and/or properties does your enabledWhen expression depend on?

PW


--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
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


Re: Programmatic handler enablement [message #540034 is a reply to message #539975] Mon, 14 June 2010 16:05 Go to previous messageGo to next message
Miles Parker is currently offline Miles Parker
Messages: 1340
Registered: July 2009
Senior Member
Hi guys,

Thanks for your quick response. The point of this is that I want to do the enablement programmatically not by relying solely on the declarative mechanism. Yes the example works in terms of the basic enablement but it doesn't seem to help the issue of programmatic enablements refining the enablement. That is, when I select a file I want to control the enablement by overiding IHandler2#setEnabled(Object evaluationContext). This works most of the time, but not always, that is there are scenarios where the setEnabled is never called.

I hope that is a little clearer.

cheers,

Miles
Re: Programmatic handler enablement [message #540089 is a reply to message #540034] Mon, 14 June 2010 20:24 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Ah, OK. setEnabled(*) will only be called at certain "checkpoints" by
the framework. It was added to try and give the handler one last chance
to align its enablement with its execution environment.

1) just before a keybinding executes the command
2) immediately before a Command#executeWithChecks(*)
3) When a CommandContributionItem needs to know if it is enabled (which
can happen on active part switching).

Outside of that, you would have to decide when to update your handler
enabled state. 2 options come to mind. Either your handler becomes a
listener for an appropriate event in your model and you update your
state then, or at some change that's important to your handler you call
handler.setEnabled(evaluationService.getCurrentState()) if using
setEnabled(*)

PW



--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
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


Re: Programmatic handler enablement [message #540095 is a reply to message #540089] Mon, 14 June 2010 21:07 Go to previous messageGo to next message
Miles Parker is currently offline Miles Parker
Messages: 1340
Registered: July 2009
Senior Member
Paul Webster wrote on Mon, 14 June 2010 16:24

Outside of that, you would have to decide when to update your handler
enabled state. 2 options come to mind. Either your handler becomes a
listener for an appropriate event in your model and you update your
state then, or at some change that's important to your handler you call
handler.setEnabled(evaluationService.getCurrentState()) if using
setEnabled(*)



Ah good, we're on the same wavelength now. Smile I do lot's of programmatic handling for various events but I should also have been clear that here I'm wanting to update based on selections in the platform views that I don't have access to, i.e. package explorer, navigator. So I need to listen to generic file selection events, basically. I realize that there is a tradeoff here for these system views because you run the danger of a lot of consumers writing complex enablement checks every time a user changes the file selection, but I'm wondering if there is a programmatic hook here.

To out things in a little more context, it might be possible that what I want to do is definable declaratively, but I need to get things like containing project builder ID that I'm very comfortable working with programmatically but I just can't figure out how to accomplish in the xml def. And I may also have things that I just need to do programmatically. So sorry if this is an obvious question, but is there a way to simply call a method on an arbitrary (adapted?) class and have the selected items passed in to it? I hope that question makes sense..

cheers,

Miles
Re: Programmatic handler enablement [message #540215 is a reply to message #540095] Tue, 15 June 2010 12:16 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Miles Parker wrote:
>
> To out things in a little more context, it might be possible that what I
> want to do is definable declaratively, but I need to get things like
> containing project builder ID that I'm very comfortable working with
> programmatically but I just can't figure out how to accomplish in the
> xml def. And I may also have things that I just need to do
> programmatically. So sorry if this is an obvious question, but is there
> a way to simply call a method on an arbitrary (adapted?) class and have
> the selected items passed in to it? I hope that question makes sense..

In the declarative XML there are property testers.
<with variable="selection">
<iterate ifEmpty="false">
<adapt type="org.eclipse.core.resources.IResource">
<test property="org.eclipse.core.resources.name"
value="*.java"/>
</adapt>
</iterate>
</with>

You can use <test/> to call a property tester [1], and the EP
org.eclipse.core.expressions.propertyTesters to define your own. We
ship with some pre-defined ones for dealing with resources [2],
including getting a projects properties and projectNature.

The caveat ... try not to put a property tester in your UI plugin, since
once the tester has been loaded the framework is free to load and
instantiate anything it feels like.


[1]
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench_cmd_expressions.htm

[2] http://wiki.eclipse.org/Command_Core_Expressions#Property_Te sters


--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
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


Re: Programmatic handler enablement [message #540335 is a reply to message #540215] Tue, 15 June 2010 17:32 Go to previous messageGo to next message
Miles Parker is currently offline Miles Parker
Messages: 1340
Registered: July 2009
Senior Member
Paul Webster wrote on Tue, 15 June 2010 08:16

In the declarative XML there are property testers.
<with variable="selection">
<iterate ifEmpty="false">
<adapt type="org.eclipse.core.resources.IResource">
<test property="org.eclipse.core.resources.name"
value="*.java"/>
</adapt>
</iterate>
</with>

You can use <test/> to call a property tester [1], and the EP
org.eclipse.core.expressions.propertyTesters to define your own. We
ship with some pre-defined ones for dealing with resources [2],
including getting a projects properties and projectNature.



OK, I got up to the example point, but where I get really stuck with the declarative stuff is when trying to work with more complex relationships. So for example, the above gives me the files with .java, but given such an adapted file, how do I then get it's enclosing project and test the properties on that? Or perhaps I do need my own property tester for this case, which would allow me to write all of that logic in Java which would probably be more maintainable. Anyway the property testers look like what I want -- I hadn't realized how open ended they were -- sort of like "EnablementProviders" really..

Quote:
The caveat ... try not to put a property tester in your UI plugin, since
once the tester has been loaded the framework is free to load and
instantiate anything it feels like.


Hmm...do you mean then that if I have a foo.ui <- foo.core then I should keep the testers and so on in a small standalone plugin like foo.ui <- *foo.resources* <- foo.core to avoid loading my other UI stuff if the users aren't actually going to be working with the adapted types?
Re: Programmatic handler enablement [message #540503 is a reply to message #540335] Wed, 16 June 2010 12:22 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Miles Parker wrote:
> Paul Webster wrote on Tue, 15 June 2010 08:16
>> In the declarative XML there are property testers.
>> <with variable="selection">
>> <iterate ifEmpty="false">
>> <adapt type="org.eclipse.core.resources.IResource">
>> <test property="org.eclipse.core.resources.name"
>> value="*.java"/>
>> </adapt>
>> </iterate>
>> </with>
>>
>> You can use <test/> to call a property tester [1], and the EP
>> org.eclipse.core.expressions.propertyTesters to define your own. We
>> ship with some pre-defined ones for dealing with resources [2],
>> including getting a projects properties and projectNature.
>
>
> OK, I got up to the example point, but where I get really stuck with the
> declarative stuff is when trying to work with more complex
> relationships. So for example, the above gives me the files with .java,
> but given such an adapted file, how do I then get it's enclosing project
> and test the properties on that?

My examples was just an example of using the property testers, not
relevant to your situation. But it depends. The core resource property
tester has a couple of project properties. projectNature,
projectPersistentProperty, and projectSessionProperty are applied
against the project of the selected resource (the PT simply goes
resource.getProject()). So if you select a java file, you can still
check its project nature.


> Or perhaps I do need my own property
> tester for this case, which would allow me to write all of that logic in
> Java which would probably be more maintainable. Anyway the property
> testers look like what I want -- I hadn't realized how open ended they
> were -- sort of like "EnablementProviders" really..

Once you write your property tester, there are some minor best
practices, but they're basically an "escape to assembler". You get a
test(*) method, return true or false :-)

> Hmm...do you mean then that if I have a foo.ui <- foo.core then I should
> keep the testers and so on in a small standalone plugin like foo.ui <-
> *foo.resources* <- foo.core to avoid loading my other UI stuff if the
> users aren't actually going to be working with the adapted types?

It's just a reminder. If you have a property tester in a plugin and
that plugin is not activated, the PT will evaluate to TRUE (technically
returns NOT_LOADED) for most of the workbench. Once the containing
bundle is active, then the PT gets to return TRUE/FALSE.

For RCP apps where they want accuracy, <test/> comes with a
forcePluginActivation attribute, to allow the core expression to load
the PT if it is not active.

Then the fallout is: If you force a PT to load, you activate that
plugin. If it contains UI elements like actionSets/popupMenus,
org.eclipse.ui.menus, commands/handlers (anything that supports delayed
loading) the framework is now free to load that contributions.

It's the standard warning that Eclipse plugins should delay loading
until a user action requests their functionality (click on a menu item
or tool item, execute a keybinding, show a view, etc).

Sometimes it's unavoidable, but you'll have to decide if putting the PT
in your core (which I'm guessing doesn't deal with resources) is worth
splitting it out from your UI plugin (which may only have a few
contributions).

Later,
PW


--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
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


Re: Programmatic handler enablement [message #540683 is a reply to message #540503] Thu, 17 June 2010 00:40 Go to previous message
Miles Parker is currently offline Miles Parker
Messages: 1340
Registered: July 2009
Senior Member
Thanks for the download Paul. Please see below..

Paul Webster wrote on Wed, 16 June 2010 08:22

Once you write your property tester, there are some minor best
practices, but they're basically an "escape to assembler". You get a
test(*) method, return true or false Smile


Sounds good to me!

> Hmm...do you mean then that if I have a foo.ui <- foo.core then I should
> keep the testers and so on in a small standalone plugin like foo.ui <-
> *foo.resources* <- foo.core to avoid loading my other UI stuff if the
> users aren't actually going to be working with the adapted types?

Quote:
It's the standard warning that Eclipse plugins should delay loading
until a user action requests their functionality (click on a menu item
or tool item, execute a keybinding, show a view, etc).


And always worth repeating. Probably like a lot of users, I end up uninstalling features that add a lot of overhead when i haven't asked for or needed the functionality.
Previous Topic:actions and keybindings
Next Topic:Java Pseudo conflict woes
Goto Forum:
  


Current Time: Fri Oct 24 18:52:33 GMT 2014

Powered by FUDForum. Page generated in 0.04787 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software