How to Undo Switching Between Modes?
-
Hello all, my script needs to work in point, edge, and polygon modes (edit modes). At the end of the script, I will switch it back to model mode, but I'm not sure how to undo the mode switching. When I run the code in point mode, I can't return to point mode when undoing
import c4d def main(): sel = doc.GetActiveObjects(c4d.GETACTIVEOBJECTFLAGS_CHILDREN) if not sel or not doc.IsEditMode(): return # edit mode doc.StartUndo() for obj in sel: doc.SetSelection(obj, c4d.SELECTION_SUB) joint = c4d.BaseObject(c4d.Ojoint) doc.AddUndo( c4d.UNDOTYPE_NEWOBJ, joint) doc.InsertObject(joint, None, obj, True) doc.SetSelection(joint, c4d.SELECTION_ADD) ... doc.SetMode(c4d.Mmodel) # set model mode doc.EndUndo() c4d.EventAdd() if __name__ == '__main__': main()
-
Hello @kangddan,
Thank you for reaching out to us. I do not quite understand your question. The document mode is just a (special) tool that is active in the document. Setting that mode is not undoable, just as activating the extrude tool is not undoable. One can quite easily test this as an end user by hitting 'undo' after changing the document mode. So, I do not quite understand what you want to do.
When you just want to revert to the previous state, just store/cache it yourself. But even that does not really make sense, as switching the document mode is not necessary for other code to run. So, when you set the document mode in code, you usually want it to stay so that user can make use of that new mode.
Cheers,
FerdinandOutput
The document mode is: 6 The document mode is: 7 Doing work ... The document mode is: 6
Code
import c4d def main(): """ """ mode: int = doc.GetMode() print (f"The document mode is: {mode}") doc.SetMode(c4d.Mpolygons) print (f"The document mode is: {c4d.Mpolygons}") print ("Doing work ...") doc.SetMode(mode) print (f"The document mode is: {mode}") # This all does not make too much sense, as our API usually does not care in which mode a document is or # provides special arguments to emulate a mode like for example #SendModelingCommand does. c4d.EventAdd() if __name__ == '__main__': main()
-
This post is deleted! -
@ferdinand Thank you for letting me know that switching between modes is irreversible! My initial thought was that when I generate an empty object in edit mode, if I undo the action, I could return to edit mode. Thanks again for your explanation
-
Hey, thanks for the video. But I still do not quite understand what you want to achieve by switching the mode. Unlike end users in a document, we can always access all data in a document, no matter the mode it is in. As an on the nose example: We can access the points of an object while not being in points mode. This makes it a bit pointless to change modes unless you want to switch the mode for the user. E.g., a plugin that extrudes a polygon and then leaves off in polygon mode so that the user can keep modelling.
There are some exceptions to this, there is for example some feature in the UV toolset which will refuse to work properly unless you are in UV mode (I always forget what feature that exactly this is until I need it and then wonder why things are not working ). But these are very rare exceptions, not to say 'cough' bugs 'cough'.
-
@ferdinand My English isn't very good, sorry about that. What I mean is that when I am in edit mode and select points/edges/polygons, create a null object, and then switch back to object mode, if I want to undo, it would be more 'user-friendly' if I could return to the previous edit mode instead of object mode
It's good to know that calling doc.SetMode(c4d.Mmodel) is non-undoable; I struggled with this for a while -
I understood that What I do not understand is why you want to do this in the first place, as changing the document mode his little impact on your code. But I guess the problem is solved for your now, so let's move on
-
I think the idea is that when working with this and testing it, it becomes a thing that the user has to manage themselves.
Imagine you have a script that takes point selections, then creates a null, and then switches to object mode with the null selected so you can immediate move the null.
You hit undo, null is gone. Back to your point object selected, but you are still in model mode. So to run it again youd need to manually switch back to point mode, THEN run the script again.
Thats what I think the idea for the use case is.
-
Well, just move the code which switches the mode to the end of your code when it is only cosmetic anyways. As I said above, a sensible way to use
SetMode
is when you want to leave the user in a state where he or she can continue working right away. But you can then just run all your code, check if everything went fine and then set your code. Otherwise you never set the mode, and therefore also have nothing to revert.It does not really break anything if you do it differently, as changing the document mode is not that much of an expensive operation. But in general, it is cosmetic call that has little impact on your code (exceptions prove the rule). The thing I wanted to emphasize here is that calling this method is mostly meaningless from an API point of view, other than the user view in the app, where the document mode is a fundamental decision which impacts many things.
Cheers,
Ferdinand -
@ferdinand said in How to Undo Switching Between Modes?:
Well, just move the code which switches the mode to the end of your code when it is only cosmetic anyways. As I said above, a sensible way to use
SetMode
is when you want to leave the user in a state where he or she can continue working right away. But you can then just run all your code, check if everything went fine and then set your code. Otherwise you never set the mode, and therefore also have nothing to revert.It's a matter of workflow. It's not simply for checking the code that it's working properly. It's about a workflow. The workflow in the example is Select some mesh components, run the command. It generates something for you and switches the mode for you. If you selected the wrong components, you'd undo and try it again. But the undo won't put you back in the component mode. The issue is that that part of the command is not undoable so it's does hinder the workflow just a bit. I'm not necessarily advocating that it should be undoable or anything like that, just explaining the reasoning in this example and the value if it were undoable.