1998-05-20 10:25:30 -04:00
|
|
|
\section{\class{wxCommand}}\label{wxcommand}
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
\wxheading{Derived from}
|
|
|
|
|
|
|
|
\helpref{wxObject}{wxobject}
|
|
|
|
|
1999-02-15 15:41:29 -05:00
|
|
|
\wxheading{Include files}
|
|
|
|
|
|
|
|
<wx/docview.h>
|
|
|
|
|
1998-05-20 10:25:30 -04:00
|
|
|
\wxheading{See also}
|
|
|
|
|
|
|
|
\overview{Overview}{wxcommandoverview}
|
|
|
|
|
|
|
|
\latexignore{\rtfignore{\wxheading{Members}}}
|
|
|
|
|
|
|
|
\membersection{wxCommand::wxCommand}
|
|
|
|
|
|
|
|
\func{}{wxCommand}{\param{bool}{ canUndo = FALSE}, \param{const wxString\& }{name = NULL}}
|
|
|
|
|
|
|
|
Constructor. wxCommand is an abstract class, so you will need to derive
|
|
|
|
a new class and call this constructor from your own constructor.
|
|
|
|
|
|
|
|
{\it canUndo} tells the command processor whether this command is undo-able. You
|
|
|
|
can achieve the same functionality by overriding the CanUndo member function (if for example
|
|
|
|
the criteria for undoability is context-dependant).
|
|
|
|
|
|
|
|
{\it name} must be supplied for the command processor to display the command name
|
|
|
|
in the application's edit menu.
|
|
|
|
|
|
|
|
\membersection{wxCommand::\destruct{wxCommand}}
|
|
|
|
|
|
|
|
\func{}{\destruct{wxCommand}}{\void}
|
|
|
|
|
|
|
|
Destructor.
|
|
|
|
|
|
|
|
\membersection{wxCommand::CanUndo}
|
|
|
|
|
|
|
|
\func{bool}{CanUndo}{\void}
|
|
|
|
|
|
|
|
Returns TRUE if the command can be undone, FALSE otherwise.
|
|
|
|
|
|
|
|
\membersection{wxCommand::Do}
|
|
|
|
|
|
|
|
\func{bool}{Do}{\void}
|
|
|
|
|
|
|
|
Override this member function to execute the appropriate action when called.
|
|
|
|
Return TRUE to indicate that the action has taken place, FALSE otherwise.
|
|
|
|
Returning FALSE will indicate to the command processor that the action is
|
|
|
|
not undoable and should not be added to the command history.
|
|
|
|
|
|
|
|
\membersection{wxCommand::GetName}
|
|
|
|
|
|
|
|
\func{wxString}{GetName}{\void}
|
|
|
|
|
|
|
|
Returns the command name.
|
|
|
|
|
|
|
|
\membersection{wxCommand::Undo}
|
|
|
|
|
|
|
|
\func{bool}{Undo}{\void}
|
|
|
|
|
|
|
|
Override this member function to un-execute a previous Do.
|
|
|
|
Return TRUE to indicate that the action has taken place, FALSE otherwise.
|
|
|
|
Returning FALSE will indicate to the command processor that the action is
|
|
|
|
not redoable and no change should be made to the command history.
|
|
|
|
|
|
|
|
How you implement this command is totally application dependent, but typical
|
|
|
|
strategies include:
|
|
|
|
|
|
|
|
\begin{itemize}\itemsep=0pt
|
|
|
|
\item Perform an inverse operation on the last modified piece of
|
|
|
|
data in the document. When redone, a copy of data stored in command
|
|
|
|
is pasted back or some operation reapplied. This relies on the fact that
|
|
|
|
you know the ordering of Undos; the user can never Undo at an arbitrary position
|
|
|
|
in the command history.
|
|
|
|
\item Restore the entire document state (perhaps using document transactioning).
|
|
|
|
Potentially very inefficient, but possibly easier to code if the user interface
|
|
|
|
and data are complex, and an `inverse execute' operation is hard to write.
|
|
|
|
\end{itemize}
|
|
|
|
|
|
|
|
The docview sample uses the first method, to remove or restore segments
|
|
|
|
in the drawing.
|
|
|
|
|
|
|
|
|