It's a style thing. Calling MemHandleUnlock()
with the original handle or MemPtrUnlock() with
the pointer returned by the original MemHandleLock()
call accomplishes the same thing.
If you have the original handle available I prefer
to call MemHandleUnlock() due to the symmetry. There
are, however, situations where this may not be possible.
For example, a routine locks the handle & passes resulting
pointer to another routine to do something with. If this
second routine wanted to unlock the memory, it would have
to call MemPtrUnlock(). The downside of this type of
assumption on the part of the subroutine is: what if I pass
it a pointer that's been allocated on the stack instead
of the heap?
For myself, I prefer to place the responsibility for locking
& unlocking at the same level -- if you locked something, you
are also responsible for unlocking it, not passing that
responsibility to some other routine. If you have symmetry in
your memory handling the possibility of memory leaks or invalid
accesses is lessened. I realize that there are situations where
this is not possible, but in most cases it is.
In the end though, it all comes down to style & personal
preference whether you unlock the pointer or the handle.
--
-Richard M. Hartman
[EMAIL PROTECTED]
186,000 mi./sec ... not just a good idea, it's the LAW!
> -----Original Message-----
> From: Ronnen Belkind [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 11, 1999 9:17 AM
> To: [EMAIL PROTECTED]
> Subject: Handles vs Pointers.
>
>
>
>
> Can someone explain this code to me. Its taken from the MailLookup.c
> CallAddressApp function.
>
> /* some code */
>
> params.title = MemHandleLock (DmGetResource (strRsc, titleStrID));
> params.pasteButtonText = MemHandleLock (DmGetResource (strRsc,
> mailLookupAddStrID));
> params.formatStringP = MemHandleLock (DmGetResource (strRsc,
> mailLookupFormatStrID));
>
> /* some code */
>
> MemPtrUnlock (params.title);
> MemPtrUnlock (params.pasteButtonText);
> MemPtrUnlock (params.formatStringP);
>
>
> Why do they lock the handle, but unlock the pointer. Why not call
> MemHandleUnlock?
>
> Thanks,
> Ronnen
>
>
>
