You're righ, in this case it isn't dangerous, but LockScreen issues can be a bear to track down.
>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.
Craig Berntson
MCSD, Microsoft .Net MVP, Grape City Community Influencer