|
|
| Re: Correct enabled/disabled widget status at startup? [message #1258538 is a reply to message #1257815] |
Thu, 27 February 2014 13:39   |
 R Shapiro
Messages: 386
Registered: June 2011 |
Senior Member |
|
|
Thanks for the reply.
I have an isEnabled() method on my handler base class that depends on selection and works fine in general: the menu items enable and disable exactly when I want them to. The problem is only at startup. All the menu items are initially enabled, which is not what I want. I want them to start out disabled. Of course isEnabled() itself is not useful here, since it's only run when the operation is executed -- too late for initialization.
The setEnabled() method for org.eclipse.core.commands.AbstractHandler doesn't take an enabled/disabled state parameter, it takes an 'evaluation context' Object. I played around with this some but never got it to do anything useful with respect to the initial enabled/disabled state. I think this is also only invoked on execution, like isEnabled(), so too late for setting the initial state.
If there's a hook that will allow me to set the enabled state "right before the menu appears", I don't know where it is. How would I do that?
[Updated on: Thu, 27 February 2014 14:00] Report message to a moderator |
|
|
| Re: Correct enabled/disabled widget status at startup? [message #1258894 is a reply to message #1258538] |
Thu, 27 February 2014 21:49 |
Erika Redmark
Messages: 22
Registered: January 2013 |
Junior Member |
|
|
Unfortunately, all my code uses actions, and there is a clear point of entry when the view loads up for me to run setEnabled, so I don't know an off-my-head solution.
The logic which determines whether or not things are enabled/disabled, is that part of the 'enabledWhen' or 'activeWhen' parts of the command when you declare your command's extension point? Or are you trying to do so programatically somewhere else? Where exactly does your logic reside that sets enabled states after initialisation; is it only in the isEnabled overriden methods for your custom handler? If that's the case, I think you may need to add an 'enabledWhen' to the extension point to re-use that code and it might make it work on initialisation.
Disclaimer: I'm not an Eclipse developer so I don't know for sure.
[Updated on: Thu, 27 February 2014 21:55] Report message to a moderator |
|
|
| Re: Correct enabled/disabled widget status at startup? [message #1259589 is a reply to message #1258894] |
Fri, 28 February 2014 15:14 |
R Shapiro
Messages: 386
Registered: June 2011 |
Senior Member |
|
|
Quote:Unfortunately, all my code uses actions, and there is a clear point of entry when the view loads up for me to run setEnabled, so I don't know an off-my-head solution.
I started with Actions, but eventually the deprecation warnings got to me and I switched to Commands. Having gone through that conversion I'm hesitant to go back.
In the Commands API, at least as I'm using it, commands are defined by classes that implement org.eclipse.core.commands.IHandler. The menu/toolbar then consists of items each of which specifies a default handler class. All my handler classes extend a base class of my own, which in turn extends the core handler class AbstractHandler. I use this pattern because the same enabled/disabled check is used for every command -- either they're all enabled or all disabled, depending on the current selection.
Quote:The logic which determines whether or not things are enabled/disabled, is that part of the 'enabledWhen' or 'activeWhen' parts of the command when you declare your command's extension point? Or are you trying to do so programatically somewhere else?
I don't see any extension points like the ones you mention. The only mechanism I can find is the isEnabled() method in IHandler. It's a simple and clean API and it works fine once the state has been initialized properly. But that's where I'm stuck -- initialization. IHandler also has an isHandled() method but it has the same initialization issues as isEnbled().
Quote:Where exactly does your logic reside that sets enabled states after initialisation; is it only in the isEnabled overriden methods for your custom handler? If that's the case, I think you may need to add an 'enabledWhen' to the extension point to re-use that code and it might make it work on initialisation.
I know I need add something but unfortunately I don't see these extension points.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03639 seconds
] 
Search
Help
Register
Login
Home
