The answer was yes; I set it to .NULL. and then released it and the appropriate file closed. Neat idea...

Renoir

>Stefan,
>
>There were a number of good ideas in this thread, but I like yours the best for my application. One question: Am I correct in assuming that if I set oGuard = .NULL. rather than issue return it should also close the appropriate file? I believe that in the case of using Return it is just going out of scope so if I use .NULL. it should have the same affect.
>
>Renoir
>
>>In some cases you can use an alternative approach that ensures there are no stray open files left but avoids "CLOSE ALL" type sledge-hammers:
>>
>>

>>local f, oGuard
>>* ...
>>f = fopen("foo")
>>oGuard = createobject([CFChanGuard], m.f)
>>* from here on you can RETURN anytime if you feel like it,
>>* without worrying about closing the file channel
>>* ...

>>
>>and elsewhere
>>
>>

>>define class CFChanGuard as custom
>>   n_FChan = -1
>>   procedure init (nFChan)
>>      this.n_FChan = m.nFChan
>>   procedure destroy
>>      if this.n_FChan <> -1
>>         fclose(this.n_FChan)
>>      endif
>>enddefine

>>Now, whenever the guard object vanishes - for example, if you leave the function scope via RETURN or because of an exception - the file channel will be closed. This is especially nice during testing because you can cancel the program anytime without worrying about stuff that might get left open. I use the same approach (which is a standard idiom in C++) for restoring various settings and releasing all kinds of resources, deleting temp files ... This stuff really grows on you once you get used to it, and it greatly helps unclutter program code.