It seems to be impossible to delete objects without showing up in the undo context…
eg:
undo off (delete $teapot01)
I get a “maxscript” entry in the undo rollout.
Whats going on? Can it be done?
I’m seeing general odd behaviour from the undo context.
The first example in the help file seems to be illogical:
[left]
[/left]
undo on
(
delete $box*
delete $sphere*
clearUndoBuffer()
)
[left]
I don’t quite see the point in that at all… you switch on the undo context, but then flush the undo stack, resulting in no undos?
Anyway, if I try:
undo "Testing" on
(
delete $box*
delete $sphere*
)
I still get “MAXscript” in the listener, and not “Testing” as I would expect.
I tried:
my_context_name="An Undo Context"
undo my_context_name on
(
delete $box*
delete $sphere*
)
I still get “MAXscript” in the listener, and not “An Undo Context” as I would expect.
I also see some people using : ‘with undo on’ rather than just ‘undo on’… whats the difference?
[/left]
[left]
[/left]
it’s nothing wrong and odd with this behavior. Every undoable expression evaluated from script listener adds “MaxScript” label in undo stack. If you execute the same expression from any UI (rollout, dialog, etc.) with “undo off” context it will not go do undo stack.
“undo off” is the same as “with undo off”.
try(destroydialog undoRol) catch()
rollout undoRol "Undo Test"
(
group "Undo ON: "
(
button bt_create_on "Create" across:2 width:85
button bt_delete_on "Delete" width:85
)
group "Undo OFF: "
(
button bt_create_no "Create" across:2 width:85
button bt_delete_no "Delete" width:85
)
on bt_create_on pressed do undo "Create Test Box" on (box name:"Test Box")
on bt_delete_on pressed do undo "Delete Test Box" on delete (getnodebyname "Test Box" all:on)
on bt_create_no pressed do undo off (box name:"Test Box")
on bt_delete_no pressed do undo off delete (getnodebyname "Test Box" all:on)
)
createdialog undoRol width:200
Thanks for clearing that up, so the undo lable only shows if executed from a ui item. What about callbacks? It looks to me like their functions always show “MAXscript”, and can’t be hidden with undo off…?
technically callback functions can’t add undo labels to the undo menu. Can you post a sample where a callback function makes some operation undoable and adds any label to the undo menu?
Something like this:
fn deletesomething =(undo off (delete $teapot*))
rollout callbacktest "Test"
(
on callbacktest open do (
teapot pos:[0,0,0]
callbacks.removeScripts id:#deletecallback
callbacks.addScript #filePreSaveProcess "deletesomething()" id:#deletecallback
)
)
try (destroydialog callbacktest)catch()
createdialog callbacktest
Prior to a save the teapot is deleted, but shows up in the listener.
this “MAXScript” undo label is caused by “create teapot” action on rollout’s open event . As I said – callback itself doesn’t add a label to the undo menu.
Still having trouble with this…is there a way to avoid the “MAXscript” entry into the undo stack with Callbacks? I have a bunch of callbacks that alter the scene with undo off, but they leave entries in the undo stack.
With oder max versions you could use your own string for the undo stack, now it always shows “MAXScript”. I think it’s a bug.
No, I think it’s like Dennis said, if the code is executed from a ui item it works as documented, and will show whatever string you assign to the undo. If you simply run it in the listener, or evaluate a script which isn’t contained within a ui item then it says MAXscript.
My problem now is that callbacks aren’t UI items, so I’m getting MAXscript show up in my undo list, even with undo off wrapped around the callback code.
There’s two MAXscript entries here, one for the teapot creation and one for the delete.
Infact just take out the teapot line, or wrap that in undo off code or clear the undo buffer…and I still get MAXscript for the delete by the callback:
fn deletesomething =(undo off (delete $teapot*))
rollout callbacktest "Test"
(
on callbacktest open do (
undo off (teapot pos:[0,0,0])
clearundobuffer()
callbacks.removeScripts id:#deletecallback
callbacks.addScript #filePreSaveProcess "deletesomething()" id:#deletecallback
)
)
try (destroydialog callbacktest)catch()
createdialog callbacktest
It doesn’t add any “undo” to the stack. Which is absolutely right.
Check yourself…
fn deletesomething = undo off
(
delete $teapot*
format "pre save ...
num objects:%
undo stack:%
" (objects as array).count (theHold.getCurrentUndoLevels())
)
try (destroydialog callbacktest)catch()
rollout callbacktest "Test"
(
on callbacktest open do
(
undo off (teapot pos:[0,0,0])
format "created ...
num objects:%
undo stack:%
" (objects as array).count (theHold.getCurrentUndoLevels())
callbacks.removeScripts id:#deletecallback
callbacks.addScript #filePreSaveProcess "deletesomething()" id:#deletecallback
)
)
createdialog callbacktest
Well, it does here:
Rollout:callbacktest
created …
num objects:1
undo stack:0
true
pre save …
num objects:0
undo stack:1
Tested in Max 2008 and Max 2010
Anyone else have any ideas? I can’t be the only one experiencing this can I… what would cause that?
I’ve just run into this again, so I thought I’d bump this thread… can people run denisTs code above and see what happens? I’m curious as to why I get undos from callbacks.