I don't think that Blitz is any different to any other language when it comes to implementing undo/redo. Typically what you need to do is maintain a list of the information required to undo the commands that the user has issued (e.g. the entity before the user turned it inside-out, or the line of text before they deleted it). This is made easier if you have a central place that processes all undoable actions. You really need to design it in from the outset.
I guess the way I would tackle it would be to use a type to hold the information on how to undo each action. You could then use the type's built-in list to traverse the undos as requested. If you are prepared to use the undocumented Handle and Object keywords than the list can be polymorphic with an id field to tell you how to treat a contained type. However, any aggregate datatype could be used. You could use a bank to hold the info perhaps.
Do you also want a redo? If so then you mustn't throw away the undo steps that have been undone until the user does something other than undo/redo!
Its a lot easier in an OO language.
Steve.
I guess the way I would tackle it would be to use a type to hold the information on how to undo each action. You could then use the type's built-in list to traverse the undos as requested. If you are prepared to use the undocumented Handle and Object keywords than the list can be polymorphic with an id field to tell you how to treat a contained type. However, any aggregate datatype could be used. You could use a bank to hold the info perhaps.
Do you also want a redo? If so then you mustn't throw away the undo steps that have been undone until the user does something other than undo/redo!
Its a lot easier in an OO language.
Steve.