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.

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

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.

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'.

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,
Ferdinand

Output

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()