I seem to be having some trouble figuring this out. On the following rollout, if I click the test button twice and then try to undo twice, it crashes Max. I sort-of understand why it is crashing, but can’t seem to figure out a way to keep it from happening. (Short of clearing the undo buffer, but I don’t want to do that because I want any /other/ interim actions to remain undoable).
try (destroyDialog RO_Test) catch()
rollout RO_Test "Test" (
local b
local s
button btn_Test "Test"
fn deleteNodes = with undo off (
for n in #(b, s) where isValidNode n do delete n
)
on btn_Test pressed do with undo on (
deleteNodes()
b = box pos:[0,0,0]
s = sphere pos:[50,50,50]
)
)
createDialog RO_Test
there is a bug in the max definition what a valid node is… there is a thread on this forum where i tell about the difference between ‘deleted’ and ‘pre-deleted’
in your case the max crashes trying delete already deleted node.
i can’t test it now but probably the changing the code to –
where isvalidnode node and not isdeleted node
fixes the crash issue, but the bug remains anyway…
Yeah, I recall that. I may have to revisit that thread as the solution was complicated and, unfortunately, adding
and not isdeleted node
does not prevent crashing.
i told there a theory (it’s true thing which works for me) how to prevent a max node from deletion.
I know we discussed some things along similar lines, but if that exact issue was something we covered, I can’t find it now.
if you do deletion with undo ON everything has to work and shouldn’t crash the max
what is ‘deleted object’?
it’s an object which was deleted but still exists in the system because can be restored with undo.
in your example you make nodes that are deleted with no chance be restored. they can stay in the system, but only staying untouched.
Correct. I don’t want the deletion of these particular nodes to be undoable. However, in the case of the project I am working on, there will be other actions which I DO want to be undoable.
This is really annoying because it can’t even be circumvented using try/catch.
by the way this is a bad mxs practice. don’t! specify a function with its undo-ability.
Yeah, I tried moving the undo-off to inside the function, as well as within the button handler, but all with the same results. I’m assuming I will have to implement the solution we came up with for the previous similar case.
let me guess… you want to create some nodes, use them, and remove them after been used… and you want to leave no trace of their existence. don’t you?
That is a fairly general but entirely accurate summary, yes. Actually, the removal of the nodes will be triggered by closing the rollout (easier to test on a button tho), and an undo at that point brings the nodes back with no way to get rid of them short of using the select-by-name control on the rollout.
I’ve tried 3 different approaches to this based on what we came up with for the “delete children of deleted object” thread, none of which seem to be working. I know it’s a bug in Max but it doesn’t seem like it should be THIS difficult to find a workaround for something so basic.