>Craig's point was that without saving the Lockscreen condition the code would be dangerous. My point that adding code that stores and restores the Lockscreen condition does not make the code less dangerous.

Not exactly dangerous, but a comical way of shooting yourself in the foot, if you have this piece of code in various places. Then in a few months you add an object which does this, somewhere deep in the containership hierarchy, completely forgetting that it will unlock the _screen on exit from its .refresh(). Then your outermost object locks the screen, starts the refresh... and this object inside just unlocks it for you, far before the refresh is finished.

With screen locking this isn't dangerous, but if it's done on some more important setting (datasession, exclusive, exact, near, ansi... you see where this can go), it may actually break the code. Which is why it's considered good practice that any code which changes an app-wide (or form-wide) setting should restore that setting before exiting. Encapsulation, in a way.