tdocview.tex

来自「Wxpython Implemented on Windows CE, Sou」· TEX 代码 · 共 325 行 · 第 1/2 页

For example, you might write a small doodling application that can load
and save lists of line segments. If you had two views of the data -- graphical,
and a list of the segments -- then you would create one document class DoodleDocument,
and two view classes (DoodleGraphicView and DoodleListView). You would also
need two document templates, one for the graphical view and another for the
list view. You would pass the same document class and default file extension to both
document templates, but each would be passed a different view class. When
the user clicks on the Open menu item, the file selector is displayed
with a list of possible file filters -- one for each wxDocTemplate. Selecting
the filter selects the wxDocTemplate, and when
a file is selected, that template will be used for creating a document
and view.

For the case where an application has one document type and one view type,
a single document template is constructed, and dialogs will be appropriately
simplified.

wxDocTemplate is part of the document/view framework supported by wxWidgets,
and cooperates with the \helpref{wxView}{wxview}, \helpref{wxDocument}{wxdocument}
and \helpref{wxDocManager}{wxdocmanager} classes.

See the example application in {\tt samples/docview}.

To use the wxDocTemplate class, you do not need to derive a new class.
Just pass relevant information to the constructor including CLASSINFO(YourDocumentClass) and
CLASSINFO(YourViewClass) to allow dynamic instance creation.
If you do not wish to use the wxWidgets method of creating document
objects dynamically, you must override wxDocTemplate::CreateDocument
and wxDocTemplate::CreateView to return instances of the appropriate class.

{\it NOTE}: the document template has nothing to do with the C++ template construct.

\subsection{wxDocManager overview}\label{wxdocmanageroverview}

\overview{Document/view framework overview}{docviewoverview}

Class: \helpref{wxDocManager}{wxdocmanager}

The wxDocManager class is part of the document/view framework supported by wxWidgets,
and cooperates with the \helpref{wxView}{wxview}, \helpref{wxDocument}{wxdocument}\rtfsp
and \helpref{wxDocTemplate}{wxdoctemplate} classes.

A wxDocManager instance coordinates documents, views and document templates. It keeps a list of document
and template instances, and much functionality is routed through this object, such
as providing selection and file dialogs. The application can use this class `as is' or
derive a class and override some members to extend or change the functionality.
Create an instance of this class near the beginning of your application initialization,
before any documents, views or templates are manipulated.

There may be multiple wxDocManager instances in an application.

See the example application in {\tt samples/docview}.

\subsection{wxCommand overview}\label{wxcommandoverview}

\overview{Document/view framework overview}{docviewoverview}

Classes: \helpref{wxCommand}{wxcommand}, \helpref{wxCommandProcessor}{wxcommandprocessor}

wxCommand is a base class for modelling an application command,
which is an action usually performed by selecting a menu item, pressing
a toolbar button or any other means provided by the application to
change the data or view.

Instead of the application functionality being scattered around
switch statements and functions in a way that may be hard to
read and maintain, the functionality for a command is explicitly represented
as an object which can be manipulated by a framework or application.
When a user interface event occurs, the application {\it submits} a command
to a \helpref{wxCommandProcessor}{wxcommandprocessoroverview} object to execute and
store.

The wxWidgets document/view framework handles Undo and Redo by use of
wxCommand and wxCommandProcessor objects. You might find further uses
for wxCommand, such as implementing a macro facility that stores, loads
and replays commands.

An application can derive a new class for every command, or, more likely, use
one class parameterized with an integer or string command identifier.

\subsection{wxCommandProcessor overview}\label{wxcommandprocessoroverview}

\overview{Document/view framework overview}{docviewoverview}

Classes: \helpref{wxCommandProcessor}{wxcommandprocessor}, \helpref{wxCommand}{wxcommand}

wxCommandProcessor is a class that maintains a history of wxCommand
instances, with undo/redo functionality built-in. Derive a new class from this
if you want different behaviour.

\subsection{wxFileHistory overview}\label{wxfilehistoryoverview}

\overview{Document/view framework overview}{docviewoverview}

Classes: \helpref{wxFileHistory}{wxfilehistory}, \helpref{wxDocManager}{wxdocmanager}

wxFileHistory encapsulates functionality to record the last few files visited, and
to allow the user to quickly load these files using the list appended to the File menu.

Although wxFileHistory is used by wxDocManager, it can be used independently. You may wish
to derive from it to allow different behaviour, such as popping up a scrolling
list of files.

By calling \helpref{wxFileHistory::UseMenu()}{wxfilehistoryusemenu} you can
associate a file menu with the file history. The menu will then be used for
appending filenames that are added to the history. Please notice that currently
if the history already contained filenames when UseMenu() is called (e.g. when
initializing a second MDI child frame), the menu is not automatically
initialized with the existing filenames in the history and so you need to call
\helpref{AddFilesToMenu()}{wxfilehistoryaddfilestomenu} after UseMenu()
explicitly in order to initialize the menu with the existing list of MRU files.
(otherwise an assertion failure is raised in debug builds).
The filenames are appended using menu identifiers in the range
\texttt{wxID\_FILE1} to \texttt{wxID\_FILE9}.

In order to respond to a file load command from one of these identifiers,
you need to handle them using an event handler, for example:

{\small
\begin{verbatim}
BEGIN_EVENT_TABLE(wxDocParentFrame, wxFrame)
    EVT_MENU(wxID_EXIT, wxDocParentFrame::OnExit)
    EVT_MENU_RANGE(wxID_FILE1, wxID_FILE9, wxDocParentFrame::OnMRUFile)
END_EVENT_TABLE()

void wxDocParentFrame::OnExit(wxCommandEvent& WXUNUSED(event))
{
    Close();
}

void wxDocParentFrame::OnMRUFile(wxCommandEvent& event)
{
      wxString f(m_docManager->GetHistoryFile(event.GetId() - wxID_FILE1));
      if (!f.empty())
        (void)m_docManager->CreateDocument(f, wxDOC_SILENT);
}
\end{verbatim}
}

\subsection{wxWidgets predefined command identifiers}\label{predefinedids}

To allow communication between the application's menus and the
document/view framework, several command identifiers are predefined for you
to use in menus.

\begin{itemize}\itemsep=0pt
\item wxID\_OPEN (5000)
\item wxID\_CLOSE (5001)
\item wxID\_NEW (5002)
\item wxID\_SAVE (5003)
\item wxID\_SAVEAS (5004)
\item wxID\_REVERT (5005)
\item wxID\_EXIT (5006)
\item wxID\_UNDO (5007)
\item wxID\_REDO (5008)
\item wxID\_HELP (5009)
\item wxID\_PRINT (5010)
\item wxID\_PRINT\_SETUP (5011)
\item wxID\_PREVIEW (5012)
\end{itemize}