Describes how to use manager views.

The following code creates a manager and a view:

The class IlvManagerView. is a subclass of the AWT class java.awt.Container. A manager view is visible when added to a parent container, that is an AWT Frame or a Swing JFrame. It becomes invisible when removed from a visible parent container.

To obtain a list of all the views attached to a manager, use the following IlvManager method:

You may also retrieve and change the manager displayed by a particular view using the following methods of the class IlvManagerView:

ManagerViewsChangedEvent

When a view is attached or detached from a manager, a ManagerViewsChangedEvent event is fired by the manager. A class must implement the ManagerViewsChangedListener interface to be notified that an IlvManagerView has been attached or detached from the manager. This interface contains only the viewChanged method, which is called for each modification:

To be notified, a class implementing this interface must register itself using the following method of the class IlvManager:

ManagerChangedEvent

When the manager displayed by a view changes, as a result to a call to setManager on the view, the view fires a ManagerChangedEvent. A class must implement the ManagerChangedListener interface in order to be notified that the manager of the view has changed and must register itself on the view using the addManagerChangedListener method of the IlvManagerView. You can also specify that the listener no longer be notified of such events using the removeManagerChangedListener method.

When the manager of a view changes, the view calls the managerChanged method of the listeners.

This method is called with an instance of the class ManagerChangedEvent as a parameter containing information on the new and the old manager.

Each manager view (class IlvManagerView) has its own transformer to define the area of the manager that the view is displaying and also to define the zoom level and rotation applied to objects.

You may retrieve the current transformer of a view using the following method:

To modify the transformer associated with a view, use the following methods:

To avoid distorting the image when it is zoomed in or out, you can specify that the vertical and horizontal aspect ratio remain the same by using the following methods:

When the KeepingAspectRatio property is on, the view ensures that the horizontal and vertical scaling are always the same, whatever transformer you set in the view.

Example: Zooming a view

The following code zooms a view in by a scale factor of 2:

The point given as an argument keeps its position after the zoom. The last parameter forces the redrawing of the view.

Transformer listeners

When the transformer of a view changes, the view fires a TransformerChangedEvent event. A class must implement the TransformerListener interface to be notified that the transformer of the view has changed, and must register itself using the addTransformerListener method of IlvManagerView. You can also specify that the listener no longer be notified of such events using the removeTransformerListener method.

When the transformer of a view changes, the view calls the transformerChanged method of all listeners.

This method is called with an instance of the class TransformerChangedEvent as a parameter. The event parameter can be used to retrieve the old and the new value of the transformer.

The library provides a convenience class that handles a manager view with two scroll bars in an AWT application: IlvScrollManagerView. This class automatically adjusts the scroll bars according to the area defined by the graphic objects contained in the manager. An equivalent object exists to be integrated into a Swing application: IlvJScrollManagerView

Double buffering is a technique that is used to prevent the screen from flickering in an unpleasant manner when many objects are being manipulated. Since the manager view is implemented as a lightweight component, that is, as a direct subclass of java.awt.Container, it cannot handle double buffering by itself. To use double buffering in an AWT environment, the manager view must be the child of a heavyweight component, specially designed to handle double-buffering for instances of IlvManagerView. These components can be of the IlvManagerViewPanel or of the IlvScrollManagerView class.

The methods of the IlvManagerViewPanel and the IlvScrollManagerView class that handle double-buffering are:

In a Swing application, the manager view is embedded in a JComponent. JComponent objects have their own double-buffering mechanism:

When you add an IlvManagerView into an IlvJManagerViewPanel or an IlvJScrollManagerView, local double buffering in the IlvManagerView instance is disabled and Swing double buffering is used instead. In specific situations, when Swing double buffering is disabled, enable IlvManagerView local double buffering by calling setDoubleBuffering after the view has been added to the Swing component.

Example: Using double buffering

This example creates a standard IlvManagerView, associates it with an IlvManagerViewPanel, and sets the double-buffering mode:

Most editors provide a snapping grid that forces the objects to be located at specified locations. The coordinates where the user can move the objects are called grid points. The class IlvGrid provides this functionality.

An instance of the class IlvGrid can be installed on each manager view. The view provides methods to set or retrieve the grid:

The following code installs a grid on a view with a vertical and horizontal grid point spacing of 10. The last two parameters are set to true to specify that the grid is visible and active:

When a grid is installed on a view, the standard Rogue Wave JViews editing interactors, such as those for creating, moving, or editing an object, snap objects to the grid automatically.

These operations are not performed by the manager, but by the interactor itself. If you want to implement this mechanism in a new interactor you create, use the following method of the IlvManagerView class in the code of your new interactor:

This method moves the IlvPoint argument to the closest point on the grid if a grid is installed and active. Otherwise, it does nothing.

The following UML class diagram summarizes the relationships between IlvManagerView, IlvTransformer, IlvGrid, and IlvManagerViewInteractor. The manager view can be contained in an IlvManagerViewPanel or in an IlvScrollManagerView object; for Swing applications use IlvJManagerViewPanel and IlvJScrollManagerView. The manager view contains a local IlvTransformer that allows the user to zoom into the view. Optionally, the manager view can contain an IlvGrid. The IlvManagerViewInteractor class handles all interactions that are specific to the view.

To improve repaint performance, the manager view allows you to skip some of the repaint requests.

When you manipulate a graphic object in a manager view, the repaint requests are sent to all views that are attached to the same manager. The view in which you are manipulating the graphic object should be refreshed as often as possible, so that you receive feedback on your manipulation in real time. This view is called the main view.

During the manipulation, it is unlikely that you would pay attention to the other views attached to the same manager. Therefore, it is not essential to keep refreshing these auxiliary view as often as the main view. It is the main view that holds the focus of the manipulation.

In a typical configuration you have the main view showing a region of a large map and an auxiliary overview showing where the region occurs in the map. When you zoom or manipulate objects in the main view, you do not need the overview to be refreshed as often as the main view.

To save CPU processing time and to gain fluidity in the main view, the refresh rate of the auxiliary views can be reduced.

When the refresh delay is set, the manager view will skip some repeated repaint requests if the delay has not elapsed since the last time the view was refreshed. You can adjust the setting of this parameter between 300ms and 800ms according to your needs. For example, to set the delay to 300ms, use the manager view method:

setRepaintSkipThreshold(300);

The default value is 0, which disables this feature.

To avoid skipping desired repaints, you can temporarily turn the view repaint mode to DIRECT_REDRAW. Repaints are skipped only under THREADED_REDRAW mode.