>Catching the _wndRefresh in the doDialog fn and re-paint the PICTURE to the
>screen works. But it is a lame workaround and if a complicated picture then
>you can see each keystroke in order.

This sounds like you are copying a multi - vector Quickdraw Picture over a
period of time instead of the main bitmap image at just one time.

>What I am trying to do is re-paint the PICTURE picHandle& to a gWorld then
>copyBits it to the active Window all at once, cleanly and quickly. As far as
>the picture bits are concerned, it seems to work "ok." The color info is
>trashed.
>
>Am I doing the gWorld "stuff" correctly? Why do some programs lock pixels?
>and when?

You can lock it at creation and leave it as such.
Otherwise Lock it anytime you are drawing into or copying from the gWorld,
unlock after.


>I am now getting color distortion.

More than likely you are changing the fore/back Color from black and white
before Copybits-ing the image. This is a known problem with Copybits.

Here is the simple fix based on my suggestion that RP offered:

LOCAL FN CopyGW2GW(sPort as long,dPort as long,sRect as ptr,dRect as ptr)
'standard utility
call ForeColor( _blackColor )
call BackColor( _whiteColor )
CALL COPYBITS(#sPort+2,#dPort+2,#sRect,#dRect,_srcCopy,0)
END FN

If you are changing the fore/back colors when painting, you need to set the
Fore/Back color as above before copybits.
Then you need to set things back to your painting colors afterwards.

But, I am having some strange similar problem when running FB 3 68K code in
a native 68K environment that the above -won't- solve.

Robert Covington