David wrote:
>    After much frustration over an obscure but fatal bug, I have pinned it down
> to the line of code below (   PICTURE (0,0), gSPLASHPICT&   ).  It only seems
> to fail after other parts of the program have run, but I don't know why.
> After those other parts have run, it fails every time and often brings the
> whole machine down.  The picture statement seems to work fine at first, and
> draws the picture correctly.  I have watched the Global Var involved and it
> does not appear to be changing value.
>    It seems to fail only when WINDOW 1 is not in front...?
>    Any clues what else might be wrong?  Everything else runs great, so I doubt
> I'm trashing memory?  I have been drawing into various off-screen g-worlds,
> and am manually switching ports to do so.  If I add the code to ALSO manually
> switch to the correct window port, it still fails just the same.  Clues
> anyone?

I can think of two possibilities:

1. You may not really have the current output window/grafport/gworld set
to where you think you have it set.  There are a few ideosyncrasies in
FB: for example, the WINDOW(_wndPointer) function does not always return
the correct pointer the the current output grafport; also, FB may switch
grafports on you even in the absence of any statements telling it to do
so: for example when the user clicks in a window's structure region,
that window becomes the current output window the next time your program
calls HANDLEEVENTS.  However, as long as the pointer which represents
the current grafport is actually a valid pointer to _some_ legitimate
grafport, I can't think of why your program would crash.

2. Your variable gSPLASHPICT& may not be a handle to a valid picture. 
For example, if your PICT resource is purgeable, then the block might be
getting purged; I think that a purgeable block _remains_ purgeable even
after you call DETACHRESOURCE on it.  If you pass a handle to a purged
block to the PICTURE statement, that could very well crash your machine.

Hope these are helpful clues.

- Rick