[futurebasic] Re: Clipboard/Memory??

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : December 1997 : Group Archive : Group : All Groups

From: Rick Brown <rbrown@...>
Date: Mon, 08 Dec 1997 23:24:33 -0600
Martin wrote:
> The 80 pictures I create are just a redraw of the onscreen picture
> fields I use for the game creator to click on as they layout their board
> game track onscreen, so I don't really won't to dispose of them.
> Each time I copy to the clipboard I loose a bit more memory. I suppose
> that is because I am not disposing of the Picture Handle properly.
> Why doesn't handl& = 0 dispose of that memory previously held by the
> picture created with picture on/off?

Ah, now I think we're homing in on the solution.

Here's sort of what's going on inside your machine:

PICTURE ON -- FB (internally) calls the "OpenPicture" Toolbox routine,
which in turn calls the Memory Manager to allocate a (small) relocatable
block.  The Memory Manager returns a "handle" to the block back to FB,
and FB holds on to that handle for later use.  The handle is a 4-byte
integer which is used to reference the block (for argument's sake, let's
say the value of the handle is 14261908).

Drawing commands -- FB passes these to QuickDraw, and QuickDraw records
the commands into the memory block that was allocated above.  Extra
memory for the block gets allocated as necessary to fit new incoming
QuickDraw commands.

PICTURE OFF, picHandle& -- FB (internally) calls the "ClosePicture"
Toolbox routine, which tells QuickDraw to stop recording drawing
commands.  FB then takes the handle it's been holding, and stores its
value into the variable picHandle&.  (That is, it sets picHandle& to

Now, the Memory Manager, which is maintaining this block for you, knows
it only as "the relocatable block whose handle is 14261908."  The Memory
Manager doesn't know how many--if any--FutureBasic variables hold a copy
of that number.

Likewise, if your FB program subsequently sets picHandle& to 0, the only
thing that happens is that the _variable_ picHandle& changes its value
from 14261908 to 0.  But no message is sent to the Memory Manager
telling it to dispose of the block which is referenced by that number.

If this were C++, there might be a way to overload the assignment
operator so that if "picHandle" is defined as a variable of type
"handle," then the statement "picHandle = 0" would trigger a call to the
Memory Manager to dispose of the associated block.  But in FB there is
no "handle" data type per se (it's just a long integer), and we can't
change the definition of "=" like they can in C++.  So assigning a
number to a long integer variable can't do anything but change that
variable's value.

Likewise, if you open _another_ picture, and store _its_ handle into
picHandle&, that doesn't make the old "14261908" block go away--It just
overwrites the value of a new handle into the picHandle& variable.  And
unless you've made another copy of the value 14261908 somewhere (say, in
a different long int variable), then you've essentially "lost contasct"
with that original block.  There's nothing you can do with the block
then--including disposing of it!

In short, if you create a block (as with OPEN PICTURE...CLOSE PICTURE,
picHandle&), you must _explicitly_ dispose of the block if you want it
to go away (it also goes away automatically when your program quits). 
Usually you would use DEF DISPOSEH() or FN DISPOSHANDLE() to do this. 
DEF DISPOSEH(picHandle&) coincidentally _also_ sets the variable
picHandle& to zero, but this is just a "side effect" that FB throws in.

Some blocks are disposed by the OS as side effects of other things: for
example, every button, edit field, etc. in a window has a relocatable
block (sometimes more than one) associated with it, and these are
automatically disposed by the OS when you close the window.  But this is
not true of the block whose handle is returned by CLOSE PICTURE.  That
one you have to dispose of by yourself.

- Rick