C H A P T E R 1 7
Additional System Services
Using Additional System Services
Using Undo Actions
The following code example shows how to provide undo capability in a view.
Imagine you have a view that uses cards. The view has a particular method,
, that it uses to delete a card. Within the
method, passing as its arguments the name of the card
deleted and a different method that will add the card (thereby undoing the delete
operation). Your call to view:
would look like the one in the
following code fragment:
// statements that delete a card
// call AddCard as an undo action
:AddUndoAction ('AddCard, [theCard])
You also need to supply the
method, which would look similar to the
following example. It too provides an undo action--one that calls the original
action, thereby completing the Undo/Redo cycle.
// statements that add a card
. . .
// call DeleteCard as an undo action
:AddUndoAction ('DeleteCard, [theCard])
The Various Undo Methods
method ties an undo action to a specific view. If that view is
no longer open when the user taps Undo, the action does not take place. Because
an undo action should generally cause a visible change, it is often desirable to tie
the undo actions to views.
When it is not desirable or feasible to tie an undo action to an open view, you can
functions to execute the undo action
unconditionally. For example, view methods usually use the
view method to post their undo action; however, if the view will not be open when
the user taps Undo, you may need to use the
functions to post the undo action. If your action relies on the view being open or
some other condition, it must test that condition explicitly.