[when to lock a handle]:
> Before you modify it ;) I lock them anytime that I am going to use them
> (with rare exceptions that I can't remember). I think that "technically"
> (or maybe bare minimum?) you have to lock them before you do anything that
> could move memory.

That's about right.  The trick is to figure out just what kinds of
operations might cause the MM to move blocks, and that is no easy
trick.  Inside Mac lists (or used to list?) all the Toolbox routines
that fall into that category.  Then we have to infer which FB statements
might be calling those Toolbox routines internally.  There are a few
general things you can say:

* LET; PEEK; POKE; BLOCKMOVE and "control" statements
  (like FOR) are all "safe";
* WINDOW; BUTTON; EDIT FIELD and such statements that
  create "objects", are "unsafe" (because they must
  allocate memory from the heap);
* File operation statements (OPEN, READ, etc.) are probably
  "unsafe" (I haven't verified this);
* The MEM(_maxAvail) function is almost guaranteed to cause
  blocks to move (and is hence "unsafe");

In general, you have to try to guess which FB statements are going
involve heap memory, and keep your handles locked while you're executing
such "unsafe" statements.  The same obviously goes for Toolbox calls
which do stuff with heap memory (such as loading resources).

And of course, this all assumes that you're "dereferencing" your handle
(i.e., that you're looking at the Master Pointer value so that you can
directly access or alter the bytes in the block).  Otherwise, you don't
really care whether your block moves, so there's no reason to lock it.

- Rick