[lazarus] TCanvas

[Samuel Liddicott]

> -----Original Message-----
> From: Shane Miller [mailto:smiller at lakefield.net]
> Sent: Monday, September 13, 1999 05:53 AM
> To: lazarus at miraclec.com
> Subject: Re: [lazarus] TCanvas
>
> I am sending a REDRAW_THE_CANVAS message right now.  I don't like that.
> See, in Windows, when I write a bunch of characters to the canvas, it
> doesn't redraw after each character, or if it does, it stops the
> redraw once
> you write to it again because it's fast.

In windows, when uou write characters to the canvas it is an instantaneous
change to that canvas.  The canvas is a context of some actual device,
either the screen, or a bitmap or a metafile.

If the canvas is a screen canvas then the changes take place on screen.  The
operation is just a *change* and anything that may have already been there
is not re-done.

Generally screen canvas's are painted in response to a WM_PAINT message.
Any canvas paints which are done in other circumstances are non-permanant
changes and will not be there next time the screen is pained because of
WM_PAINT.  (Usually there is nothing persistant about a screen image).  A
few controls do paint outside of WM_PAINT, mainly where:
a) There are lots of small changes in a small area
b) These small changes are also included in the WM_PAINT updates

examples are TEDIT and TMEMO controls.

> Under Linux, I am telling it to redraw when I'm done sending all the text.
> There must be a method in Windows for controlling this, like only draw the
> canvas (if needed) every 500 ms or something.  If I write 200
> characters to
> the canvas, I don't want it to actually update the screen until
> 1) I'm done drawing
> or
> 2) There is a pause in the drawing..

In delphi, this is what InvalidateWindow is for.
Refresh is an Invalidate+Update which is not what you want.

A mere InvalidateWindow will tell windows that the window needs painting.
Then, when there are no more other messages, windows will send out the
WM_PAINT and then the window is painted.

The general method from your point of view is probably NOT to paint the
window in response to key-strokes and stuff, but to instead update edit
buffers and other structures so that when the paint message comes along you
can paint the invalid'd region of the window.

Maybe GTK doesn't support idle anyway, but [I hate to say it] lots of Delphi
stuff relies on it, so we should simulate it some way.

Does this make sense?

Sam