#116 a real "undo" instead of this one

[Anonymous]

Since creationorder IS generally important, especially when concerning datastructures, I'd like to have a real "undo". For example if I delete something from my patch and click "undo" it will not be "undeleted" but it will be recreated - as if I would have done it manually! Thus changing the order of creation!!

So what we have now is not really an "undo" since the actual state is not restored.. This can lead to nasty bugs and confusion!! And it does - don't use undo, just to be on the safe side..

I actually I don't know how the patch-data is stored before it has been saved to harddisk, but it can't consume too much space, since the savefiles are not that big either..
So could one solution just be to "store" the last, say 50, steps one did in separate patches, as if one would have saved the patch to separate files after each step, and then reload the appropriate one on "undo-action"???

[IOhannes m zmölnig]

generally, "undo" is great, esp. if your undone objects don't have any internal state (think functional programming!)
obviously this won't work good when dealing with datastructures (which are only "state").

as you noticed, "undo"ing a deleted object will re-create it from scratch (so all internal state is lost).
this can be nasty in some situations.
otoh, what you propose, is to recreate the entire patch from scratch, which would re-initialize about everything (in that patch). i think that this is far more dangerous.

image in object that interacts with hardware (e.g. video-capture) and needs an exclusive handle to a given device.
it is not trivial to make an undo for such an object.

[Nobody/Anonymous]

I didn't think of internal states at all by now..
Just imagine "stacking" some ds-graphics. So you have a [struct]-subpatch containing some [drawpolygon]'s. One for each graphic/layer. Now since the layers should stay in a certain order to not mix up the graphics, the creationorder of the [drawpolygon]'s becomes important.
The "delete - undo"-stuff will rearrange the layers though. And if one doesn't pay attention, one would not even see a thing since the creationorder is not visualized at all.. ...why not make it visible with colors or a scope or somehow else...???
I mean losing the internal state on "undoing" is something someone rather can expect to happen..

I can think of two ways internal states can be set. That's manually/spontaneously by the user or automatically that is in the end with a [loadbang] on opening a patch.
Now the last possibility would be covered by the "save-the-whole-patch-after-each-action-to-a-new-file--and-load-one-of-those-on-undo"-undo-behavior ..what the...
Apart from that, one would lose all user-set internal states instead of only the one(s) of the "undone" object(s)..

So it's like "keeping creationorder" vs. "keeping (most) user-defined-states" ?!???

..If so, to impart just my opinion, I think "keeping creationorder" is more important, 'cause normally people don't create patches which they don't save in the end, maybe as an "abstraction" or a "normal" patch.. So at last on reloading it, the user-defined internal states are gone anyways. ..but "creationorder-bugs" will be saved within the file for the future; and will, to think of the worst, accumulate.