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