How to Use UMLData Events and Event Filters
Event receivers must implement the _IUMLDataEvents interface in order to receive one or more of following possible events from IUMLData objects:
Sent immediately before the UML data is erased from the model. If multiple data are erased, this event is sent for every IUMLData (not only for the topmost one).
Sent when the UML data is added to the model tree. If multiple data are added in one step (e.g. a class with multiple attributes is added to a package) only the topmost IUMLData event is sent.
Sent when the UML data has been modified (e.g. when a class name is changed).
Sent when the UML data has been moved to a new parent (e.g. when a class is moved to another package in the ModelTree).
This event always occurs twice: once when detaching from the old parent, and once when the UML data is attached to the new parent.
Eventfilter can be set with (combinations of) ENUMUMLDataEventFilter in order to specify which events should be sent by the UModel API. To keep performance high and the overhead as low as possible, event receivers should only register for events they need.
For example, the following code registers OnAfterAddChild events when specifically the root-package gets a new child (no event will arrive if a child of the root-package gets a new child):
// ensure we get informed when m_RootPackage (and only itself; we do not care about its children) gets a new child
UMLData events work hierarchically, so the event filter can be set to receive events from the attached IUMLData only, or from the attached IUMLData and any of its children (grandchildren,...).
// ensure we get "OnBeforeErase" events also for *any* erased child (grandchild,...) of the rootpackage
UMLData events are also sent when UML data is modified by Undo / Redo, but beware that no UML data modification may be made during Undo / Redo:
public void OnAfterAddChild(IUMLData ipUMLParent, IUMLData ipUMLChild)