]>
Commit | Line | Data |
---|---|---|
1 | \section{\class{wxCommand}}\label{wxcommand} | |
2 | ||
3 | wxCommand is a base class for modelling an application command, | |
4 | which is an action usually performed by selecting a menu item, pressing | |
5 | a toolbar button or any other means provided by the application to | |
6 | change the data or view. | |
7 | ||
8 | \wxheading{Derived from} | |
9 | ||
10 | \helpref{wxObject}{wxobject} | |
11 | ||
12 | \wxheading{Include files} | |
13 | ||
14 | <wx/cmdproc.h> | |
15 | ||
16 | \wxheading{See also} | |
17 | ||
18 | \overview{Overview}{wxcommandoverview} | |
19 | ||
20 | \latexignore{\rtfignore{\wxheading{Members}}} | |
21 | ||
22 | \membersection{wxCommand::wxCommand} | |
23 | ||
24 | \func{}{wxCommand}{\param{bool}{ canUndo = FALSE}, \param{const wxString\& }{name = NULL}} | |
25 | ||
26 | Constructor. wxCommand is an abstract class, so you will need to derive | |
27 | a new class and call this constructor from your own constructor. | |
28 | ||
29 | {\it canUndo} tells the command processor whether this command is undo-able. You | |
30 | can achieve the same functionality by overriding the CanUndo member function (if for example | |
31 | the criteria for undoability is context-dependant). | |
32 | ||
33 | {\it name} must be supplied for the command processor to display the command name | |
34 | in the application's edit menu. | |
35 | ||
36 | \membersection{wxCommand::\destruct{wxCommand}} | |
37 | ||
38 | \func{}{\destruct{wxCommand}}{\void} | |
39 | ||
40 | Destructor. | |
41 | ||
42 | \membersection{wxCommand::CanUndo} | |
43 | ||
44 | \func{bool}{CanUndo}{\void} | |
45 | ||
46 | Returns TRUE if the command can be undone, FALSE otherwise. | |
47 | ||
48 | \membersection{wxCommand::Do} | |
49 | ||
50 | \func{bool}{Do}{\void} | |
51 | ||
52 | Override this member function to execute the appropriate action when called. | |
53 | Return TRUE to indicate that the action has taken place, FALSE otherwise. | |
54 | Returning FALSE will indicate to the command processor that the action is | |
55 | not undoable and should not be added to the command history. | |
56 | ||
57 | \membersection{wxCommand::GetName} | |
58 | ||
59 | \func{wxString}{GetName}{\void} | |
60 | ||
61 | Returns the command name. | |
62 | ||
63 | \membersection{wxCommand::Undo} | |
64 | ||
65 | \func{bool}{Undo}{\void} | |
66 | ||
67 | Override this member function to un-execute a previous Do. | |
68 | Return TRUE to indicate that the action has taken place, FALSE otherwise. | |
69 | Returning FALSE will indicate to the command processor that the action is | |
70 | not redoable and no change should be made to the command history. | |
71 | ||
72 | How you implement this command is totally application dependent, but typical | |
73 | strategies include: | |
74 | ||
75 | \begin{itemize}\itemsep=0pt | |
76 | \item Perform an inverse operation on the last modified piece of | |
77 | data in the document. When redone, a copy of data stored in command | |
78 | is pasted back or some operation reapplied. This relies on the fact that | |
79 | you know the ordering of Undos; the user can never Undo at an arbitrary position | |
80 | in the command history. | |
81 | \item Restore the entire document state (perhaps using document transactioning). | |
82 | Potentially very inefficient, but possibly easier to code if the user interface | |
83 | and data are complex, and an `inverse execute' operation is hard to write. | |
84 | \end{itemize} | |
85 | ||
86 | The docview sample uses the first method, to remove or restore segments | |
87 | in the drawing. | |
88 | ||
89 |