> > More importantly, removing the listeners in an > > unsynchronized fashion, as is currently done, opens a window for > > events to be lost during the period in which no listeners are > > registered. > > Yes, that is a potential problem. > This problem may occur if the model changes when registering > listeners again, not when removing.
Actually the change may already have occurred and have an event queued to be delivered. Model changes and listener registration/deregistration happen in a different, unsynchronized time domain from event delivery. (ie different threads) > > For #2, > > is it more complex than adding a listener when we receive > an relevant > > AddAssociation event and removing a listener when we receive a > > RemoveAssociation event? > > Yes, you also have to register the listener in the first > place, i.e. on load of the project. > If you add something, then you mayhave to add a lot of other > listeners, too. And if you remove e.g. the operation of a > class, then you also have to > remove the listeners to the operation's parameters & stereotypes. Doesn't this decompose in a hierarchical fashion? When you first place a Class on a diagram, you get a list of all the Operations and for each one do addOperationListeners() or something similar which knows about adding listeners for Parameters, Stereotypes, and whatever else is appropriate. When you get an AddAssociation event for the association 'feature', you invoke the same method which does all the same stuff. Removing an association or removing the entire Class from the diagram works similarly in reverse. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
