( Sorry for the previous repetition (I thought it would have been edited out.)
But I am encouraged that my posts got through at all, and so, as
Leonard Cohen sang, "I'll try to say a little more". )
Now I think that the artifact in question is really quite easy to explain after
all,
at least in principle. And that it is sort of an important principle. So I'll say
what's occurred to me about it.
I had a vertical splitter on the left side of a RichEdit, with the splitter's
onRelease()
handler making the RichEdit and the splitter move in tandem.
And, say, the splitter and the RichEdit were originally at absolute position x1.
And that the splitter is then moved to absolute position x2, within the area
of the RichEdit (---i.e., to relative position x2-x1 in the RichEdit).
A feed-back image of the splitter appears while moving it from x1 to x2.
Apparently this feed-back image of the splitter remains on,
at x2, during the onRelease method.
And apparently the Move() function used to move the RichEdit
is essentially a simple bitblt (bit block transfer) type of move
(close to being a simple machine instruction, and very efficient.)
But the result is that the feedback image of the splitter, which is still on
during the onRelease() and the Move(),
is simply transferred along with the other bits of the RichEdit
when the RichEdit is Moved()!
Then, when the splitter's onRelease method returns,
the feedback image of the splitter at x2 is erased,
but an echo of it remains in the RichEdit,
at the same relative position x2-x1 it was in before,
but now at absolute position x2+(x2-x1).
This can be done several times, leaving several echo artifacts in the RichEdit,
because Move() just moves bits around the screen and does not itself
force your program to re-draw anything. Windows lets you decide the right time
to do that.
So I tried Update(), Redraw(), and InvalidateRect(1),
on the main window at the end of the splitter's onRelease handler.
And InvalidateRect(1) worked (for me.)
Thinking about it again, it's probably nanoseconds more efficient
to apply the InvalidateRect(1) to the RichEdit (or whatever's been moved
or changed) rather than to the whole window. And of course InvalidateRect()
can be targeted at even more specific rectangular areas.
The general principle being that what ever it's applied to should at least
cover the echo of the splitter, in order to eliminate that artifact.
~Greg.
