Yeah, yeah... I already remember two vital things: save the state and restore it after. Why would I want to remember more things for the same purpose? :)

>Nick;
>
>Just sub class the clean up class! :)
>
>For simple or "cookie cutter" applications using a class for clean up looks desireable. For the real world - I like to do it the "hard way" - with code! :) Perhaps it a matter of style also.
>
>Tom
>
>
>>And then I need to remember the name of this class, how to call it, etc. What if somebody wants the class which sets/restores TALK ON instead of OFF? Create another class, or add two methods to SETTALK class (or one method and pass the parameters), remember methods names, etc... Sure you can do things this way, but for such simple cases, IMHO, it is not worth it. But that's just me... :)
>>
>>>Hi Nick,
>>>The advantage is: you don't have to remember to cleanup. When the procedure/method ends, the variable goes out of scope and the destroy() cleans up for you.
>>>
>>>>I personally do not see very big advantages in having the class for such cases. Those 3 lines are clear and self-sufficient. You will replace them with two lines. What's the big deal? :)
>>>>
>>>>>Every time I see code written by someone else I always see things like:
>>>>>

>>>>>Procedure ??
>>>>>  lcTalk = Set('Talk')
>>>>>  Set Talk Off
>>>>>  .........
>>>>>  Set Talk &lcTalk
>>>>>EndProc
>>>>>