Community
Participate
Working Groups
The UMLEditor adds a CommandStackListener to its CommandStack in UMLEditor#initializeEditingDomain, but it doesn't remove it when closed. This is not an issue for normal use, but we have a case where the CommandStack is shared with another editor. It causes an SWTException "widget is disposed" when the UMLEditor is closed. Note that this is a problem that seems shared by every EMF editor (the reflexive EcoreEditor and every generated editor). version : org.eclipse.uml2.uml.editor_3.1.100.v201009281840
How have you customized the editor so that it shares its command stack? Perhaps the editor could also be customized (in the same place) so that the command listeners are removed? If this is truly a shared problem, I'm inclined to fix it in EMF (by modifying the codegen template)...
We have not customized the UML editor. We have added an action that opens a table model editor from a selection of EObjects, from which we get a model (this works in any model editor, not just the UML editor). To edit this model in our model table editor, we use the editing domain of the original (UML) editor through the interface IEditingDomainProvider which it implements. And the command stack is obtained through EditingDomain#getCommandStack.
Ed's not so keen on doing anything in EMF to deal with this. To fix it in UML2, I would suggest having the UML editor implement CommandStackListener and remove itself from the command stack when it's disposed. We can perhaps look at this for Keppler (since it's effectively an API change).
Created attachment 220467 [details] A proposed fix Attached a patch that fixes the problem, not by changing the inheritance structure of the UMLEditor class, but simply by refactoring the command-stack listener as a new protected field (following the example of other listeners). This allows subclasses to intercept the listener before it is added to the command-stack, which I suppose is why the other similar fields all have protected visibility (if it were my choice, they would all be private). Anyhow, this is an addition to the API, so the patch is based on the Kepler (master) branch. The patch is in Git's e-mail patch format.
The fix has been committed and pushed to the 'master' branch in git.
An integration build containing the fix is now available.
