Mike Parker wrote: > As I see it, the problem is not directly related to the handlers, but to the > commands themselves, which (being typically defined in the plug-in's > plugin.xml file) are instantiated by the platform only once. Thus, if two > command contribution items in two workbench windows are associated with the > same command ID, they are also referencing the same command object. Since > this command can, in turn, only be associated with (at most) one handler at > any one time, and this handler is responsible for determining the commands > enabled status, it is (as Mark says) impossible to enable the command > contribution item in one workbench window, whilst keeping the command > contribution using the same command ID in the other workbench window disabled > (or vice versa).
Yes, this is a limitation of the current system. The command is a singleton object, and the context it operates against is the global application context. Since enabled was written as "state" for the command and the handler, all UI elements reference the command will reflect the same enabled state, even if not appropriate. You can also create the problem with a command in a multi-instance view toolbar (since multiple views can be visible at one time, the tool item state reflects the command state based on the active view, not its local view). > > However, the above-mentioned problem does NOT occur with the "Save" toolbar > item in Eclipse 3.4. Right, the actions have both behaviour, semantics, and rendering information all tied up in one object. That allows them to reflect a localized state fairly easily. > (Note: Maybe this should be bugzilla'd, so that we have a handle on this > problem?) There should be a couple of bugs, although they might have been closed in the 3.x stream. > > In order to fix this issue, surely it would be necessary to (optionally) > instantiate a command once per workbench window, rather than once per > workbench. This might solve the multi-window case, but not the multi-part case (like my multi-instance view example). Some investigation seems to indicate that we need to activate, enabled, and execute our handlers all within the same context. That way the print icon in one workbench window would be asking isEnabled(context) within its window context, and would not be effected by a different workbench window context. Check out http://dev.eclipse.org/mhonarc/lists/eclipse-incubator-e4-dev/msg00356.html We're investigating a number of aspects of this problem in the 4.0 stream. Later, Paul Webster -- 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/help33/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/workbench.htm _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
