Content-change events in nested managers

Defense > Programmer's documentation > Advanced Features > Nested managers and nested graphers > Content-change events in nested managers

When the content of the manager changes, for example, when an object is added or removed or when the bounding box of an object changes, the manager fires a ManagerContentChangedEvent event. Any class can listen for the modification of the content of the manager by implementing the ManagerContentChangedListener interface. This mechanism is described in Listener for the content of the manager.

Registering such a listener in a manager using the method addManagerContentChangedListener of the manager allows the listener to receive Content Changed events only for modifications that are taking place in the manager where the listener is registered. A listener registered using this method will not be notified, for example, when a new graphic object is added to a submanager.

NOTE 	Such a listener can nevertheless receive events indirectly due to some modifications in submanagers. For example, when a new graphic object is added in a submanager B of a manager A, the nested manager B may change size, so a listener registered on A may receive an ObjectBBoxChangedEvent due to the insertion of a new graphic object in B.

In order to receive all Content Changed events of a hierarchy of nested managers, the IlvManager class allows you to register a global listener, with the methods:

void addManagerTreeContentChangedListener (ManagerContentChangedListener

listener)

void removeManagerTreeContentChangedListener (ManagerContentChangedListener

listener)

Such a listener registered on the top-level manager of a hierarchy will receive all the Content Changed events of the hierarchy. To distinguish which submanager has sent an event, you can use the method getManager on the event; the event is an instance of the class ManagerContentChangedEvent and contains the method:

IlvManager getManager()

NOTE 	You can register a global Content Changed listener on the top-level manager to detect all insertions of submanagers in the hierarchy of managers. If you do this, you must take into account the possibility that a manager that already contains some managers might be added to a manager. In this case the listener will not receive an event for each of these managers.