Just so that you know, I changed our code to better
follow the Windows port and now I don't have the
problem anymore. I am now using the cached PS that
comes back from the begin paint rather than using
the DC that is already selected into the widget and
the bug is gone. During my bug hunt also tried
to select out and destroy the clip region after
the BitBlt in CopyOffscreenBits. Didn't seem to
have any effect on my 'mouse turd' bug. So the evil
must involve more than just the clipping region.
In my opinion making a
unique element for the cursor seems like a bit of
overkill. I think ideally it would be nice to recognize
that we are trying to start the cursor blinking during
some kind of paint event and then try to queue the
cursor StartBlinking to be the next event executed. The best
I could do was a mEventQueue->PostEvent and then I created
a CaretEvent to post. But when I coded this, the change
would cause the cursor to basically disappear
during rapid typing. Then it would show back up when
the typing stopped long enough to have the caret
event processed. That also solved the my bug, but
that side effect was too obnoxious.
Thanks for your replies.
--Aaron
Adam D. Moss wrote:
> Simon Fraser wrote:
>
>> The caret lives in a dangerous world, since it has to draw
>> directly to the screen in XOR mode, which causes fighting with
>> the copying of offscreen bits. This is the cause of a number
>> of 'caret turd' bugs, and forces the caret code to create a new
>> rendering context for each blink.
>
>
> Would it be a better idea to render the caret as a black-white-
> blinking floating element, say? I can just see this as being
> a lot less weird codewise (not that I'm volunteering).
>
> --Adam
