FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

MEMORY

Know when to lock handles


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


By _not_ using HUNLOCK you leave the handle in whatever state it was in before you modified it. If you use HLOCK on a locked handle, no harm done, if you then use HUNLOCK on a handle that was originally locked you could have problems. HSETSTATE will set the handle to whatever you got from HGETSTATE, so if it was locked it'll be locked when you are done, if it was unlocked it'll be unlocked when you are done.

*Chris