Saving Unique File... But only few times? - (project bug)

You wrote "if I just press and RELEASE CTRL by itself... it will create an UNDO"

If you are using the flag correctly, this should not happen. When you press and release Ctrl or any other button, without actually changing any objects, undo step will not be saved. Only when anything about the object has been modified (scaled, moved on z-axis etc.), then you set the flag and undo step will be saved.

If the undo needs to be saved, and it is saved, then why did you wrote that it is a problem and that it doesn't make sense? (your words, not mine) :)

English is not my first language either, so there may be a misunderstanding on my part. Anyway, I hope you'll get everything working exactly as you want.

If the undo needs to be saved, and it is saved, then why did you wrote that it is a problem and that it doesn't make sense? (your words, not mine) :)

English is not my first language either, so there may be a misunderstanding on my part. Anyway, I hope you'll get everything working exactly as you want.

That's right, I believe it's a misunderstanding (probably because I can't explain it better) your English is GREAT!

In overall: the most important part is that the ORIGINAL bug is gone.

What I tried to explain above is that the current "solution" is not the most efficient one, and I wish I could find a replacement for it based on the cursor wheel ALONE (without holding a button and releasing for sake of UNDO) in other words: saving the Undo only AFTER I scroll without crashing, which is impossible since it's saving to the Undo History too fast and that's what causing the original crash so I MUST use an EXTRA key to release, so it will cool-down the rate of saving undos.

What I was looking for is a way to do the SAME (save undo) but WITHOUT any extra keys while scrolling up/down... not possible unfortunately and very incontinent for my software and the users.

BUT! I'll just move on since the error is not there, that's the plus! :)

AFTER I scroll

Its easy to make custom event, that will be triggered when user stop scrolling.

A quck example: drive.google.com/file/d/1CUUe5aoDkdxJyfV1KOWbCrcDPETb6ORH/view

Note that this method waits for a pause in scrolling, which is not an ideal solution in your case. If you keep this timeout at 0.3s, for users who scroll slowly (when they want to precisely adjust object size), undo will be saved every 0.3 seconds, which is still too frequent.

If you set a larger timeout like 1-2 seconds, undo step will be saved with a big delay, during which user may do something else, for example delete the object. And this again can cause the situation when two undo steps are saved at the same time.

Why did you make the delay even smaller? This means saving lots of unnecessary undo steps. Not only it can cause bugs, but also will make it more difficult for user to undo.

Make sense, it's hard to make it work perfect for all machines but 0.3s may be too slow so I need to test it.

Sure it works great on your PC, but on an older machine with a slow HDD saving a big project may take much longer time. 0.1s is probably good for my specific machine true I must play with it.

The thing is that since it's ONLY be used for the Z-Order event my main goal was to immune that crash like an extra "Safety Layer" but I guess combined with the way the undo works I rather be careful and not use this cooldown for anything else so I won't cause delayed undos and a mess for the users.

Regarding the number of steps - it depends on the average size of each save. Add some objects, open browser console, it should tell you the amount of data saved, in bytes. Multiply by the number of steps - that's how much memory the array will take.

That sounds scary! because the user may create and tweak MANY objects over the canvas and tweak them around. From my current tests: I didn't have any issues with large amount of objects on the screen, no slowdowns no delays But once again... my computer is average+ I don't want to ruin the experience on older machines if it's an option.

I doubt you will run out of memory even with 256 undo steps, but a very big array may be slow.

That's encouraging! because I'm thinking about 64-128 UNDOS so I won't need to even give the user a need to change it manually.

Thanks dop2000 that's VERY helpful!

And I'm saying that even 0.3s is not enough, especially if you anticipate users will be adding lots of objects. I've seen save/load actions taking more than 5 seconds.

You need to make a proper system that doesn't allow two or more saves running at the same time.

And I'm saying that even 0.3s is not enough, especially if you anticipate users will be adding lots of objects. I've seen save/load actions taking more than 5 seconds.

You need to make a proper system that doesn't allow two or more saves running at the same time.

OH MY! That's REALLY good to know, thanks for sharing your experience! it sounds too risky if so, than maybe I should consider go back to the addition Release Key + Mouse Wheel for the extra safety? what do you think?

My older version (before the delay) I used CTRL + Wheel Scroll UP/DOWN and once Releasing the CTRL the save undo function execute.

The problem was that even if the user just Press and Release CTRL by itself it saves extra undos, this is why I didn't like it...

Maybe a better solution is to combine on: Release CTRL + Wheel Scroll Finished (without delay?) for giving the OPTION for the "Scroll Finished" I didn't try it yet but I'm curious if I should.

Unfortunately I don't see other solutions for "After Wheel Released" WITHOUT any extra Releasing key beside the current one which may cause issues on different machines now that I realize it.

I wonder, are you using "No save" behavior?

Yes, on anything that is not the instances such as GUI panels and such, anything that I don't need to save for next session.