pittenger-laurence@cs.yale.edu (Laurence Arthur Pittenger) (05/13/91)
Here's a tricky one (or so it seems to me) -- not your ordinary moving
memory problem at all.
- I create a structure:
ObjectHandle object = (ObjectHandle) NewHandle (sizeof(ObjectRecord))
- Then I lock it before initializing the fields: HLock (object); I'll
unlock it when done w/ initialization.
- In the course of initializing various fields I call:
{
CGrafPtr curPort;
CGrafPort tempPort;
GetPort (&curPort);
OpenCPort (&tempPort);
... < do stuff here >
SetPort (curPort);
}
- when the OpenCPort is executed, however, elements in my object get
screwed up.
What may be a problem, though I don't understand how, is this: my
object is actually an extension of a control. I wanted to add some
extra fields to the control record so that I didn't have to dive into
my cdefs each time I just wanted to get a value or flag. So I have:
typedef struct
{
ControlRecord theControl;
<more fields>
} ObjectRecord, **ObjectHandle;
This way I can typecast handles to my objects as a ControlHandle, and
so treat them like controls, or use them directly to get the other
fields.
One of the things I do with these handles is use ControlManager stuff.
Is it possible that when the environment is set up for my cdef (which
is where the OpenCPort command is), only the Control part of my object
is protected, because the manager assumes my object is a control and
doesn't protect the remaining info? This seems unlikely, though,
because, if I understand correctly, the MemoryManager handles all this
stuff independently, and so it knows how long the allocated memory is,
regardless of how the handle has been cast.
And yet, in the face of this, if I don't have these extra fields it
works fine -- that is to say, OpenCPort isn't messing up just *any*
memory, it leave my control info alone, but it screws up any fields
used to expand the control record.
Pleeeese send advice, 'cause I'm *really* stuck (with *very slow*, if
not crashing, code) otherwise.
thanks in advance,
LP
--
Laurence A. Pittenger
CSNET : pittenger-laurence@cs.yale.edu
BITNET : pitlaua@yalevm , pittenger-laurence@yalecs