What happens if win1 gets closed/removed? To answer this question, ask you another one: is the action reversible?
1. Case where the closing/removal action is reversible:
The closing/removal event is recorded in the undo stack, and when the user is performing undos, it un-does the closing/removal.
For example, when a user removes, through your application, a file win1, the app should not remove the file, but only mark it as a candidate for removal; then, a potential undo will un-mark the file.
2. Case of irreversible actions:
If you're talking about irreversible actions, given that the reversibility is not depending of your application, then deal with it, for example by disabling the corresponding undo elements.
For example, you're writing a tool which manages server farms, and at a given moment, the server win1 is materially unplugged from the network. In this case, your application can't replug the server, since it requires human intervention.
The application should then adapt its behavior in a more intuitive way: cancel or undos anterior to the irreversible one, skip the irreversible action, or something radically different and innovative. It's up to your interaction designer to come with the most intuitive way.
This is not much different from a case such as when your application tries to access a database, but the database is offline: you can't do anything about it, and the way you behave depends on the precise context.
Example:
Let's take an example from your comment: the removal of an Excel sheet. The successive actions are:
- Change the cell A1 in sheet 1,
- Change the cell A1 in sheet 2,
- Remove the sheet 1.
Two possible behaviors would be:
The reversibility of sheet removal. Strangely, Excel team have chosen to not make it reversible. While this is probably motivated by some technical aspects I ignore, this behavior is totally wrong UX-wise. As a user, when by mistake I destroy a sheet, I expect to be able to get it back by pressing Ctrl+Z.
Not being able to do that makes it risky to use Excel, since I can never know what could be reverted, and what could result in a loss of work. That's not nice at all.
The impossibility to remove the sheet with the loss of "Change the cell A1 in sheet 1" step in the undo stack after the removal. Technically, it's not so difficult. Imagine the following structure:
class undoEntry
{
string text; // Text which is displayed to the user in the undo history.
sheet? correspondingSheet; // The sheet where the action happened, or null.
undoAction action; // The action to undo.
}
With correspondingSheet property, you can then walk though the undo stack when a sheet is removed, and delete the entries you shouldn't display any longer.
