Community
Participate
Working Groups
3.2 We have an object contribution whose selectionChanged method simply hangs onto the selection, but does not change its enabled state. Previously (I believe as recently as the 3.2 release candidates), this action would always be enabled as long as it met the selection criteria (right kind of object and size) specified in the plugin.xml. Now it's disabled by default, and remains disabled since we don't change the enablement in code. I believe this is due to the following optimization in SelectionEnabler: // Optimize it. if (mode == UNKNOWN) { return false; } Since the action delegate is in the same plugin as the view (and its plugin is therefore activated), it gets instantiated fairly early when reading the extension (set a breakpoint in its constructor to see this) and the corresponding PluginAction gets its enablement updated with false. This doesn't get changed later.
Created attachment 52702 [details] Zip of test plug-in The following test plug-in shows the problem. Steps: - show the SampleView view - select one of the items - bring up the context menu - the Test Action item is disabled - if you uncomment the setEnabled(true) line in TestAction, it's enabled
Assigning to component owner PW
The mode is unknown in your example because it won't accept 1+ as enablesFor. When mode==UNKNOWN it just means it wasn't able to parse the enablesFor element. If the attribute is not there at all, it gets set to ANY_NUMBER. I'd prefer to leave the behaviour (as it indicates a problem with the action definition). But we could set the mode to ANY_NUMBER by default and just log the parsing error. PW
Wow, I guess I should have checked the schema. So I need to use '+' instead of '1+'. We could definitely improve the error checking / reporting here. A log entry would be good (e.g. using the RegistryReader.logError helpers).
Actually, for object contributions, enablesFor="+" is redundant. Still useful for the other kinds of contribution though.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.