> Ok, so I think I am on to something here.  I actually am
> discovering that the BitBlt machinery gets really angry
> when an instance of Color coming from GOODS has, as its
> cachedBitPattern instVar, a KKObjectProxy rather than
> the unproxied bitmap it was expecting.

That is to be expected. Mind you BitBlt runs as a primitive which means it 
does NOT send any messages but rather does hard type checks on the iVars and 
fails if it sees anything that doesn't look correct.

> So -- is this a BitBlt problem that it won't take a
> ProtoObject (in this case, an instance of KKObjectProxy)?
> Or is there a way to ensure that an object coming out of
> GOODs always gets totally unproxied (yuck)?  Too bad that
> BitBlt doesn't handle this better, but I suspect it is looking
> for an instance of a variable subclass and, instead, it finds
> an instance of ProtoObject and gives me the fraction? error.

That is correct. One way to deal with this would be to have a method like 
(for example) #unproxy which you can send to the iVars of BitBlt and which 
answers true if any of them have been unproxied. Then you could fix the 
failure code to check any of the (relevant) iVars and whether they have been 
unproxied and retry (a very similar mechanism is used for Form>>unhibernate 
which is a nice example for that mechanism).

> The really hard thing to solve is that it is not the Color
> instance of my Morph that is problematic.  It is rather the
> instance variable "cachedBitPattern" of the Color instance
> that is causing BitBlt so much grief.  I am looking for a
> direction to go here if anyone can provide advice.

Simple: Don't store the cachedBitPattern. As the name says it's a cache and 
therefore there is no reason to store it with the rest. Alternatively, dump 
it when the color comes back in (this is less efficient in space terms but 
might be easier to implement).

Cheers,
  - Andreas