Description Unknown User 2001-10-10 22:45:59 EDT

Dirk from Zurich would like to contribute an action set containing actions which reflect
the selection in a text editor.  There are some problems.

"
- IWorkbenchWindowActionDelegate only receives structured selections changes.
I didn't find a way to track text selection changes right from  the beginning. As a result I 
have to keep the action enabled all the time.
- if a plugin gets loaded without a selection changed event, the action delegates don't get 
instantiated and we can't adjust the enable state.  This is only possible after the first structured 
selection change.
"

NOTES:

DS (9/25/01 9:39:41 AM)
	First the details: PluginAction only forwards IStructuredSelections to the action delegate.
	It drops simple ISelections on the floor.

	Now the workaround:  When the delegate is created we call an init(IWorkbenchWindow) method.
	The delegate should add a selection listener to the window in the init method.  Unhook the
	listener in the dispose method.  If this approach is taken you will get any selection fired out by 
	the text editor.

	Will your delegate compete with the PluginAction to enable the action?  I don't think so.
	If an IStructuredSelection is made the plugin action will process the selection and then
	call selectionChanged on the delegate.  You may override the action.  If an ISelection
	is made the plugin action will ignore it, and your own processing within the delegate
	can do the right thing.

	This problem in PluginAction will delay the accurate enablement of the action.  However, I do 
	not think this is very different from similar scenarios within the workbench.  For instance ..

	Action enablement is currently defined by xml.  Unfortunately, a number of plugins contribute 
	window actions with enablement criteria which cannot be described in our xml.  There is no 
	way to enable these actions correctly before they are instantiated, so the only solution is 
	to enable the action initially in xml so that the user can invoke it.  After the action has 
	been invoked the delegate can do the right thing.  An "error dialog" may appear 
	once, when you run the action for the first time, but only if the action is the first thing 
	in the plugin to be loaded.

	In Dirk's scenario we have an action which does not receive selection events.  I suspect
	that it is also impossible to define the enablement criteria for the actions correctly in this
	case, so this is just a variant on the scenario above.  Action enablement is only correct
	after the delegate has been created.  If the action enablement criteria in xml is always 
	enabled then the delegate may control the enablement with confidence after it has 
	been instantiated. 

DB (26.09.2001 10:33:35) 
	Hooking a selection changed listener on the selection service I can access via the workbench window doesn't solve
	the problem since I don't know the menu bar's action. The desktop doesn't pass the "real" action in the init method
	so I don't know which action to enable or disable. I only get the tool bar's action in run and selectionChanged. May be
	we should change the interface and pass the action on init and remove it from run and remove the method 
	selectionChanged.

	I know that I have to deal with the case that the action can be activated even if it can't work on the selected item. But we
	think that this is not the normal case. The refactoring actions make only sense in a perspecitive which deals with Java 
	elements so we assume that the user only adds the action set in those cases. If so, the Java plugin is loaded anyway and
	the desktop instatiates all action delegates implemented by JDT on the first selection change. If we could change the
	behaviour that the action delegates get instatiated on plugin loading (without triggering a selection change) than the
	enable/disable state of the contributed actions are correct in 99% of the cases.

DS (9/26/01 9:17:17 AM)	
	If we change (a) the point of instantiation to be plugin load, and (b) the selectionChanged
	strategy in PluginAction there is no need to change the interface.  When the plugin loads
	we can instantiate the action and then call selectionChanged, regardless of the current
	selection in the workbench.

	Note: If we did change the interface it wouldn't be a "change", it would be the "addition of	
	a new interface", so we would have IWorkbenchWindowActionDelegate and
	IWorkbenchWindowActionDelegate2.  

	All of these changes are only effective for 2.0, of course.  What version are you
	developing on?

DB (26.09.2001 16:10:09)
	Yup that's correct. The only advantage of changing the interface would be, that the action itself could deceide if it is interested
	in selection changes, instead of implementing an empty method. This would be consistent with the rest of the desktop, where
	I have to register a listener to get informed about selection changes. But changing the API is a bad approach too.

	I am developing on the 2.0 stream.