TextView registers as listener without unregistering

[Matthias Schoettle]

In certain cases the TextView registers itself as a listener for referenced objects without unregistering first. This is the case when the old value of the notification is null.

For example, if the constraint of an InteractionOperand is not set (OpaqueExpression body is null), this will happen.

[Matthias Schoettle]

Resolved issue #142: Unregister always before registering again. But only if the value hasn't changed.

→ <<cset a6836a75b4f1>>

[Matthias Schoettle]

Another problem exists, where the TextView does not unregister itself from the feature. This happens, when data.eGet(feature) (i.e., the new value) is null. Instead, the previous value should be checked, whether the listener needs to be unregistered.

For example, this happens with ParameterValueMapping where the value is added and can be removed or replaced later.

[Matthias Schoettle]

Resolves #142: Adds the consideration of the old value when unregistering a listener for the feature reference. This ensures that the view is properly unregistered if that reference changed or was set to null.

→ <<cset e9ac3d6483bc>>

[Matthias Schoettle]

There is an issue that prevents the unregistering of the second listener (on a referenced object), since the value of the feature changed and therefore cannot be retrieved.

This mainly happens when removing a complete object. For example, removing the ClassifierMapping and the operation. The oldValue might not be the one corresponding to the feature.

[Matthias Schoettle]

Resolves #142: Fixes unregistering of referenced object's item provider. The item provider that the TextView registers on is now remembered, which allows for unregistration in any case independent of what changed.

→ <<cset 905aeec7ca29>>