A manager coordinates the interactions between the display of graphic objects in multiple views and the organization of graphic objects in multiple storage places. This is illustrated in Manager Concept:

To introduce some of the important concepts related to managers, the following items are described:

Instances of the IlvManager class handle a set of graphic objects derived from the Views class called IlvGraphic. When you organize graphic objects that the manager coordinates, you create an unlimited number of graphic objects and place them in multiple storage areas. These storage areas appear in superimposed layers. That is why they are called manager layers.

A manager is therefore a tool designed to handle objects placed in different priority levels . Priority level here means that objects stored in a higher screen layer are displayed in front of objects in lower layers.

Each graphic object stored in a layer is unique to that layer and can be stored only in that layer.

Graphic objects stored throughout the manager all share the same coordinate system.

A manager uses one or multiple views to display its set of graphic objects. These views are instances of the class IlvView and you can connect as many as you want to the manager.

A geometric transformation (class IlvTransformer) can be associated with each view connected to a manager. When drawing its graphic objects in a view, the manager will use the transformer of the view, thereby providing a different representation of the same objects in each view (zoomed, unzoomed, translated, rotated, and so on).

All events are handled by means of event hooks, view interactors, object interactors, or accelerators. These are described briefly here and in more detail in section Manager Event Handling.

The IlvManagerEventHook class is intended to monitor or filter events dispatched to the manager.

Interactors are classes designed to handle user interactions involving a single or a complex combination of events.

An accelerator is an association of an event description with a user-defined action. In other words, when the event occurs the manager calls the action. This very basic interaction mechanism is limited to a single response to a single event, such as double-clicking with the left mouse button or pressing Ctrl-F.

The IlvContainer class already provides ways of handling graphic objects. However, you may require more powerful features. Here is a list of circumstances under which you might need to use a manager:

Managers provide a solution to these problems. They also offer advanced features that complex graphic applications may need:

Objects can be manipulated and views can be changed by means of instances of the IlvManagerCommand class. This class has been designed to give IlvManager the ability to undo and redo changes.

Instances of the IlvGraphic class can deal with input/output. Similarly, the IlvManager class has a set of member functions to read and write object descriptions. Manager properties, such as the layer or name of an object, can also be read and written.

When manipulating thousands of overlapping objects, redrawing operations can be very time-consuming. They can also be unattractive if each redrawn element reappears sequentially on the screen. These problems can be avoided by using the double-buffering technique implemented in IlvManager. When this feature is activated, all drawing functions are performed in a hidden image; when the area has been completely updated, the image is drawn at once in the working view.

This mechanism, based on the classes IlvManagerObserver and IlvManagerObservable, allows the application to be notified when certain modifications are done to the manager (adding or removing a view, setting a transformer on a view, adding graphic objects, adding or removing a layer, and so on).

Specific actions can be triggered under predefined circumstances. The manager view hooks let you connect events that occur in a manager with actions to be performed. This will be described in more detail in section View Hooks. Some application tasks performed with view hooks can be implemented with observers.

This tool allows you to force mouse events to occur only at locations defined by a snapping grid.