Or maybe sometimes I do.”

Then DON’T press Undo, depending on your intent.

Your solution is more restrictive than what I proposed without giving any advantage. Why reset the buffer? If you don’t want to ‘undo’ also the code, copy it or don’t press the ‘Undo’ button. As you know, we must to keep in sync the Dfm and Pas. Also, another option would be at the step in which one presses the ‘Undo’ in a different context, perhaps a Don’t-Show-Again dialog would say ‘We revert a change from ” (ie. Form / Code)

Also I rather see a single Undo Stack / DFM+PAS entity. But the items in this stack have different types. Hence the structure will be something like (not optimized, just an example):

type

TUndoItemType = (uitDFMPASSnapshot, uitEditor);

TUndoItem = record
  Kind: TUndoItemType;
  GeneralSnapshotData: //whatever...
  EditorUndoData: //the undo structure which we have now
  //...etc.
end;

It is possible to change any property of TForm1.ClientDataset1 while TForm1 is not opened in designer. One should open TForm2 and expand DataSource1′s property Dataset.

However, whereas in the code editor one would probably work around the problem by caching the code affected by task A in the clipboard or an auxiliary edit buffer before undoing, such techniques are more difficult and error-prone if both code and UI changes are involved. This makes it tempting to resort to Jolyon’s dodge of providing undo only during an uninterrupted session in the form designer (or better, until manual changes are made in the code editor).

Perhaps in the short term that’s the best that could be hoped for, but a system that allows undoing out of sequence where possible should be the eventual goal. Ideally, you could work freely within the undo history of an entire project across multiple sessions.

So, here is practical implementation:
1) Change occured (button moved, for example)
2) DFM file is in memory.
3) Undo engine always have previous DFM file, before the change.
4) Engine make reverse differential compression (original – current file, new – file before change). And leaves it in memory.
5) As soon as changes become too numerous all old changes could be dumped to disk using FIFO principle.
6) One undo requires only one simple decompression. And you must note that normal text edit operations could be implemented inside compression scheme (as it uses insert and delete operations already) to speed up things.

Is it hard to implement? No, it is not.
It is not as facinating as playing with various properties changes and similar things. I know young boys, they like that

And, btw, this post also shows biggest mistake made by Delphi developers – separating DFM and PAS files (and later making DFM binaries). ALl DFM data must be included within form class declaration and must be contained in same PAS file. So, we could return to elegant units concention as opposed to idiotic project conception.

If I make a mixture of code changes and form design “tweaks”, when I “undo” a form design change I do not (always) want any intervening code changes undone:

1. Place a control
2. Add some code
3. Move the control
4. Add another control
5. Move the control placed at #1 above
6. Add some more code
7. Re-arrange code (I have a preference for how methods are organised in a unit that doesn’t always agree with the IDE default placement of the code)
8. Review my form design (i.e. return to form design view)

So now imagine I’m sitting looking at my FORM design and decide that I didn’t want to move that control (at step #5) after all.

So I “Undo”.

But I do NOT want the code changes I made at #6 and #7 to be undone.

Or maybe sometimes I do.

I think the only way a form design Undo could work would be for a given Form DEsign activity context. That is, for as long as I am working in the form designer I can undo any changes I make. But as soon as I switch to a code editor view my form design undo buffer is reset.

Now that might work.

It might not be perfect, but it’s better than nothing and avoids the problem of trying to handle undo across separate and not always related edit contexts (code + form design).