Undo/Redo

[admin]

Maybe, but the current implementation seems to work well, and I have other things to do, and the undo part is near to impossible given the current undo architecture in XY.

[zer0]

Maybe, but the current implementation seems to work well, and I have other things to do, and the undo part is near to impossible given the current undo architecture in XY.

I can't see how you can say that it works well when a handful of power users are speaking to the contrary. I also recall that you were quite proud of how agile your code is, so this sudden inability to re-architecture undo feature is quite puzzling

[admin]

Maybe, but the current implementation seems to work well, and I have other things to do, and the undo part is near to impossible given the current undo architecture in XY.

I can't see how you can say that it works well when a handful of power users are speaking to the contrary. I also recall that you were quite proud of how agile your code is, so this sudden inability to re-architecture undo feature is quite puzzling

You wouldn't speak like this if you knew how complex undo is under the hood.

IIRC the "seems to work well" was directed to the button labels (Cancel versus Stop), but I was not in the mood to make many words... and since it's generally true as well (I'm a power user too and I use this function LOTs of times without any problems) I left it at that.

[zer0]

You wouldn't speak like this if you knew how complex undo is under the hood.

IIRC the "seems to work well" was directed to the button labels (Cancel versus Stop), but I was not in the mood to make many words... and since it's generally true as well (I'm a power user too and I use this function LOTs of times without any problems) I left it at that.

I appreciate that undo is complex -- apologies if I sounded dismissive of that fact -- but it has this bug. It would probably be a different story if file operations were controlled by Windows and it wasn't telling you all that you need to know. However, since in my case the copy/move is handled by Undo's sibling XYcopy The Second, the two should work in synergy. When I copy dozens/hundreds of files, which I often do, I seldom want to have to go manually through and select those that were copied for deletion. This is particularly true when not all of them are destined for the same directory. Granted, there is a case to be made that if one is careful and thorough, one would not need to cancel things in progress. But if we were all to be like that, Undo/Redo would be obsolete.

[LittleBiG]

Long time no speak, thread

By the way of undesired behaviour, I recently discovered that if I cancel a move of a couple of files half way through, the Undo mechanism doesn't register that a file has been moved. Thus, it is not possible to undo it being moved. Should it be possible? Yes, it should be possible to undo any partially-done action. XYcopy knows the source and destination. Also, what file(s) have been processed are known. We just need for Don to sprinkle some coding magic and voilà!

Yes, I admit the imperfection you described, but alas, I have to postpone improving it. There are so many other interesting things to do.

I would like to urge it as well. Couple minutes ago, my move was interrupted, so half of my files was on the old place, and the other half was in the new folder. I have tried to roll back (because I wanted to choose a new destination to move), but my last move was missing from the undo. Since my destination folder contained files already before moving, I had to pick the moved files one by one manually, in order to restore the original state.

I hope you will change your mind. UNDO is so great, it is worth improving. Except that XY would be the first to give a solution this kind of problem.

[admin]

It's on my list.