Document Handling Components

Table of Contents DocumentRegistry Component StandardFileCommands Component AutoDocumentService Component MainWindowTitleService Component Topics in this section

Several ATF components provide services document handlers can use.

Many of the sample applications use all of these components. Some of these components depend on each other, as noted in the discussion below on component requirements.

DocumentRegistry Component

As previously discussed, the DocumentRegistry component tracks open documents (objects implementing IDocument) for an application and implements IDocumentRegistry.

To use this component, simply add it to the application's MEF catalog. It doesn't import anything, so no other components are required to use it.

However, other components import and require IDocumentRegistry: StandardFileCommands, AutoDocumentService, and MainWindowTitleService — the other components discussed here. Therefore, you must provide DocumentRegistry or some other component implementing IDocumentRegistry to use these other components. Other components besides these also import IDocumentRegistry, such as CommandLineArgsService, which parses and validates command line arguments. These components all need and take advantage of the document tracking services DocumentRegistry offers.

For additional information on this component, see IDocumentRegistry Interface and DocumentRegistry Component.

StandardFileCommands Component

StandardFileCommands implements File menu commands that modify the document registry: New, Open, Save, SaveAs, Save All, and Close. New and Open commands are created for each IDocumentClient component in the application.

In other words, including this component in your application automatically adds all the usual menu items you need to handle documents.

StandardFileCommands is the only ATF component that implements IDocumentService and can be used to satisfy such an import. For instance, the AutoDocumentService component imports IDocumentService.

StandardFileCommands requires (except as noted) the following:

• DocumentRegistry component or some other component implementing IDocumentRegistry.
• CommandService component or component implementing ICommandService.
• FileDialogService component or component implementing IFileDialogService.
• StatusService component or component implementing IStatusService (requested but not required).
• IDocumentClient implementer for each document type.

These requirements are easily met by including the indicated components in the application's MEF catalog — except for the last one: document clients implementing IDocumentClient. The application must implement IDocumentClient for every document type it supports. For details on doing this, see Implementing a Document and Its Client.

Note that the application can implement as many IDocumentClient implementers as it wishes, because of the form of the import:

[ImportMany]
private Lazy<IDocumentClient>[] m_documentClients;

For an example of using StandardFileCommands in an application, see StandardFileCommands.

AutoDocumentService Component

When an application starts up, AutoDocumentService automatically opens the application's last open document or a new, empty document.

AutoDocumentService requires the following (except as noted):

• DocumentRegistry component or some other component implementing IDocumentRegistry.
• SettingsService component or component implementing ISettingsService (requested but not required).
• CommandLineArgsService component (requested but not required).
• IDocumentService implementer, such as StandardFileCommands, to open an existing document.
• IMainWindow implementer, which is met by creating a MainForm component.
• Form implementer, which is met by creating a MainForm component.
• IDocumentClient implementer for each document type to open a document.

Most of these requirements are easily met by including the indicated components. MainForm derives from Form and implements IMainWindow, so it satisfies two of the imports, as noted.

The last requirement is the most demanding: the application must implement IDocumentClient for every document type it supports. For details on doing this, see Implementing a Document and Its Client. Just as for StandardFileCommands, the application can have as many IDocumentClient implementers as it wants.

MainWindowTitleService Component

MainWindowTitleService updates the application main form's title to reflect the current document and indicate whether it is dirty or not.

MainWindowTitleService requires the following:

• DocumentRegistry component or some other component implementing IDocumentRegistry.
• IMainWindow implementer, which is met by creating a MainForm component.

Topics in this section