Skip navigation links
org.netbeans.core.multiview/1 1.71

MultiView Windows
Stable

MultiView Provides support for creation of editors composed from multiple (independent) elements.

See: Description

MultiView Windows 
Package Description
org.netbeans.core.api.multiview
MultiView API lets the developers create new multiview components (without specifying their content), manipulate existing multiview components, eg.
org.netbeans.core.spi.multiview
MultiView SPI provides infrastructure for creating components that dock multiple views into one consistent component.
org.netbeans.core.spi.multiview.text
MultiView Text provides integration between multi view infrastructure and common textual framework.

MultiView Provides support for creation of editors composed from multiple (independent) elements. One can either specify the elements directly or read them from a declarative registration for a particular mime type.

What is New (see all changes)?

Use Cases

There is an introduction to MultiView and its usage in its javadoc. It covers the major part of available usecases. Here is just a list of frequently asked or interesting questions slowly expanding as people ask them:

MultiView faq:

How does serialization work?
Q: How does serialization of multiviews work and what needs to be serializable?

First of all, you don't need to worry about serialization if all your MultiViewDescription instances contained in the multiview state to be non serializable. Meaning they all return TopComponent.PERSISTENCE_NEVER in MultiViewDescription.getPersistenceType().

If at least one of the views requires serialization, you have no choice but to make all MultiViewDescription implementors serializable. You also can persist the MultiViewElement instances that the multiview contains. The algorithm here is a bit complicated for performance reasons. Only those Elements are stored that were created during the session and which are Serializable. So if the user never switches to the 4rd tab, and it's corresponding element and visual component never get created, then it won't be stored. (We would have to create it just for the sake of persistance). So if your visual component needs some inital context for creation, you should store it in the description instance, and if the visual component wants to store it's state (location of cursor, selected field, something else that makes sense for the opened component) you should store it in the MultiViewElement. So basically if you are always able create the Element from Description without any persisted data, you don't need to persist anything.

If you define your own CloseOperationHandler implementation for the multiview component, then you also ought to define it Serializable. Otherwise it will be silently replaced by the default handler on restoration of the multiview component.

How to set the display name?
Q: How do I set the display name for the multiview component?

Each MultiViewDescription defines display name and icon. While the icon is meant for the whole document/view tab, the display name is just for the inner switching button. So how does one set the name for the whole MultiView component? It can be done when creating the component.

    TopComponent mvtc = MultiViewFactory.createMultiView(myDescriptions);
    mvtc.setDisplayName("My static mvtc displayName");

Later in the lifecycle of the component, it can be also influenced from within the individual multiview visual elements using the MultiViewElementCallback.updateTitle() method.

Exported Interfaces

This table lists all of the module exported APIs with defined stability classifications. It is generated based on answers to questions about the architecture of the module. Read them all...
Group of java interfaces
Interface NameIn/OutStabilitySpecified in What Document?
MultiViewExportedStableoverview-summary.html

Provides support for creation of editors composed from multiple (independent) elements. One can either specify the elements directly or read them from a declarative registration for a particular mime type.

Group of preferences interfaces
Interface NameIn/OutStabilitySpecified in What Document?
multiview.toolbarVisibleExportedUnder Development

The visibility of toolbar is controlled by a preference shared with editor module. The multiview implementation listens and uses following property:

    MimeLookup.getLookup(MimePath.EMPTY).lookup(Preferences.class).getBoolean("toolbarVisible", true);    
    

to find out whether all toolbars in all multiviews should be visible or not. Also, since 1.25, the toolbar is hidden completely. There is a tab switching action in multi view component popup menu to compensate this.

Group of branding interfaces
Interface NameIn/OutStabilitySpecified in What Document?
org.netbeans.core.multiview.MultiViewElement.Spliting.EnabledExportedUnder Development

By default a MultiViewElement allows the containing TopComponent to split it. Some systems may however find this not of any use. Then they should brand the MultiViewElement.Spliting.Enabled to false. NetBeans IDE by default does allow spliting.

Implementation Details

What do other modules need to do to declare a dependency on this one, in addition to or instead of a plain module dependency?
Nothing.

Read more about the implementation in the answers to architecture questions.

Skip navigation links
org.netbeans.core.multiview/1 1.71