git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@11 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
		
			
				
	
	
		
			86 lines
		
	
	
		
			2.8 KiB
		
	
	
	
		
			TeX
		
	
	
	
	
	
			
		
		
	
	
			86 lines
		
	
	
		
			2.8 KiB
		
	
	
	
		
			TeX
		
	
	
	
	
	
| \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}
 | |
| 
 | |
| \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.
 | |
| 
 | |
| 
 |