What is the best mechanism to handle undo buffer in SDK? In maxScript we have “undo on” or “undo off” context. How we can achive this in SDK? This is what I got so far:
At the begginig I do:
global_interface.TheHold.SuperBegin();
and a the end I do:
global_interface.TheHold.SuperAccept("Done");
The problem is this dos’nt work somethimes and I lost the buffer completely and I can’t get previuse buffers as well.
you want undo on/off:
TheHold.Suspend()
TheHold.Resume()
for recording an undo-action
TheHold.Begin()
TheHold.Accept(“name of undo action”)
for grouping multiple undo actions
TheHold.SuperBegin()
TheHold.SuperAccept(“name of super-action”)
for more info see: hold.h in maxSDK
PS: this forum drives me crazy:
even when logged in, this thing asked for another login for reply, which it refuses with an error anyways
after 3 browser restarts and cookie cleaning i could finally get a ‘cleaner’ login,
but then that funny thing showed the hole page as text not html ?
so another restart
and the tried to reply, then it presented 5 time a 403 error until it finally decided to let me do things a forum is supposed to allow without hickups
WTF is going on here, some kiddies using the newest javascript framework and think they are developers ?
what about learning some things you want to do ? not let a framework or generator do it for you.
ridiculous, to say it mildly
now what will happen when they play with ai-generated code ?
sorry, need to vent a bit,
and as always, the incompetent amateurs responsible for this mess don’t even care about it.
Do you think we had to accept previus actions before begin? like this:
TheHold.Accept(“Before”);
TheHold.Begin()
my personal anti-record is 16 times * * now I count it every time I fail to upload the first time
you can nest undo Begin/Accept
theHold has an internal counter adds on begin, szbtract at accept, when this counter reaches zero, an undo-entry will be generated, with name og the last Accept
it depends what your code does
ie. A() and B() are undoable
calling A() then B() – you get 2 undo-entries, one for A(), one for B()
if A calls B – you get ONE undo-entry, the name is A, on undo both actions A() and B() are undone
if you want to call A() and after that B(), but want only one undo-entry for them you need to use SuperBegin/SuperAccept
The UNDO/REDO mechanism in the SDK differs from MXS.
MXS utilizes pre-existing UNDOs for specific methods provided by the system and does not allow the creation of custom undo/redo objects. In the SDK, the RestoreObj class serves this purpose.
Developers are responsible for implementing UNDO/REDO functionality for a method (operation).
While some SDK methods have system-implemented “undoability,” most do not.
Using the theHold wrapping (Begin, Accept) does not guarantee that the block will be undoable.
Determining whether a specific method is undoable or not is not straightforward. The only way to ascertain this is by trying it out. If it turns out to be non-undoable, you’ll need to create your own RestoreObj for it.
You can find numerous examples of a RestoreObj implementation in the SDK.