Tony wrote:
> I'm using an ENTERPROC% routine that passes a long input string to my
> function, which creates a handle to a new long output string. Thinking
> that I was following the manual's advice "Don't leave handles locked!",
> I locked the output string just after I created it, then unlocked it
> just before I handed it back to the caller.
> 
> Sometimes this worked, sometimes it didn't. A couple of days ago, I went
> back to the manual and this time got a different take. I decided I'd
> better emulate the nearby example code, putting lock/unlock calls around
> each section of code that used the handle. 

Haven't seen your code, but I suspect that what could be happenning is
that, after you initially locked the handle, you might have called some
other function that unlocked it "behind your back."  For example:

LOCAL FN myFunction
  :
  OSErr = FN HLOCK(theHandle&)
  :
  FN doSomething(theHandle&)
  :
  OSErr = FN HUNLOCK(theHandle&)
END FN

Now, FN doSomething may _also_ do a HLOCK and HUNLOCK on the handle, in
which case the handle will be in the _unlocked_ state when FN
doSomething returns.  So any subsequent code in FN myFunction that
assumes that the handle's still locked may not work.

One way to get around this is to call FN HLOCK _again_ after returning
from every function like FN doSomething.  But there's a more elegant
solution, and that's to make sure that all of your functions (such as FN
doSomething) leave the handle in _whichever_ state it was originally in,
at the time the function returns.  Basically: FN doSomething would
record the handle's initial locked/unlock status, then lock or unlock it
to its heart's content, then _restore_ the old status before returning.

Of course, if FN doSomething happens to be an OS function, you have no
such control.  And I think there are OS functions which are guilty of
not restoring the handle's original status when they return.

- Rick