Donald Ziesig via Lazarus
2018-05-03 21:15:42 UTC
Hi All!
I have written a control that works fine except that it produces the
subject WARNING twice for every time it is painted. The problem comes
from a single line:
Canvas.Draw(0, 0, Bitmap);
I do much drawing to the Bitmap's Canvas (behind the scenes to avoid
flicker) before calling the Draw method.
I have stepped through this call and sure enough, it calls
InvalidateRect twice before returning. Otherwise it does exactly what
it is supposed to do.
Unfortunately, the calls it makes to DebugLn are time consuming and
produces a noticable delay in program execution when I try to paint.
The source code (in gtk2winapi.inc) does not offer a way of disabling
the warning message. Googling for the message said that it should never
be left as is, but I can't see any way around calling Draw from within
an OnPaint handler. Also, sample apps do the same thing!
I could bite the bullet and comment out the DebugLn in the source, but I
worry that that is "a hack to far".
Suggestions as to how to overcome this problem will be truly appreciated.
Thanks,
Don Ziesig
--
I have written a control that works fine except that it produces the
subject WARNING twice for every time it is painted. The problem comes
from a single line:
Canvas.Draw(0, 0, Bitmap);
I do much drawing to the Bitmap's Canvas (behind the scenes to avoid
flicker) before calling the Draw method.
I have stepped through this call and sure enough, it calls
InvalidateRect twice before returning. Otherwise it does exactly what
it is supposed to do.
Unfortunately, the calls it makes to DebugLn are time consuming and
produces a noticable delay in program execution when I try to paint.
The source code (in gtk2winapi.inc) does not offer a way of disabling
the warning message. Googling for the message said that it should never
be left as is, but I can't see any way around calling Draw from within
an OnPaint handler. Also, sample apps do the same thing!
I could bite the bullet and comment out the DebugLn in the source, but I
worry that that is "a hack to far".
Suggestions as to how to overcome this problem will be truly appreciated.
Thanks,
Don Ziesig
--