Bill,

>I too set all my settings in the Private DS, but I still find that I need to change something and restore it when I'm done. Examples: I will need to re-Select() an alias, or I have to restore an On Error setting (those are the only 2 I can think of off the top of my head). How do you handle those kind of situations?

For area, I just resort to the 3 simple lines

local lnSelect
lnSelect = select()
...
select (lnSelect)


I'm not sure encapsulating those three lines of code in a class is all that beneficial. An object is definately a heavier weight solution.

ON ERROR is not ever an issue because that error handler only has a couple of dozen lines of lifetime in the main.prg. Since I have overridden the Error() method of my lowest level subclasses errors in method code never hit the ON ERROR handler.

>Also, it sounds like all of your methods ASSUME certain settings. I do the same thing, and I have always had this bug in the back of my mind that I was doing it wrong. I've always squelched the bug by reminding myself that I'm the only one that will ever work on my apps.

The SET environment is pretty well defined in my case. If you are writing general purpose UDFs then you do have to worry about it more. Assumptions can be quite hazardous. Using your SET management class assumes that classlib is in the path or else you have to write defensive code like

set classlib to SETManager additive
loSetDeleted = createobject( "cSET", "deleted", "off" )

Is it worth writing all of the set classlibs or just assume (require) that the environment has been properly established to allow you to just do the createobject()?