Hi Tom, thank you for you insights.
> I'm sorry if the next few line will add even more to your frustration > because what you are doing here is just plain wrong :-(. > Abuse of @CanExecute > -------------------- > You are abusing @CanExecute for something it is not designed for. First > of all @CanExecute sole purpose is to control the enablement/disablement > of a command - point. I get that. That's why I wrote that using "Using @CanExecute for this seems like a hack, as I don't really determine the handler's executability". > You further assume that the command is bound to a MMenuItem but it might > as well get bound to a keybinding, toolbar item. In this case, no. I am talking about a *Direct* Menu Item here, so MyHandler is not a real Handler (in the Applicaton Model sense) but just some class with an @Execute method. > The correct solution: > --------------------- > The correct solution is to use an Addon who listens to the preference > change, querys the model to find the required MMenuItems, ... and > setting the check-state of the MMenuItem. Your handler should never ever > access the MMenuItem, MToolBarItem it should just flip the preference > (as I said it might get triggered by a keybinding!) *If* I had a *Handled* Menu Item, then the key binding thing is indeed a problem. Note, however, that I could just ask for an MItem, which is very generic (but still doesn't exist in the key binding case). > Look at [1] where I do something like that in efxclipse application, it > uses our preference story and does some more complex things but i think > you get the idea. So you are essentially saying that I have to implement an add-on that maintains some kind of preference -> tag mapping and then, whenever a preference changes, looks for all model elements with the corresponding tag and updates their selection state. This quickly gets ugly if we are talking about multiple preferences: The addon would need an @Inject @Preference method for each of these preferences. At the same time, the different handlers would still need to know about the preferences as well, as their job is to change their respective preference. Having to spread this logic across several classes doesn't feel very elegant. Best wishes, Andreas -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940
signature.asc
Description: OpenPGP digital signature
_______________________________________________ e4-dev mailing list e4-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/e4-dev
