S> If I got it right, I may use WinBeginPaint() ... WinEndPaint()
 S> without having to wait for the receipt of a WM_PAINT message.

You don't have it right,  sorry.

In non WM_PAINT code,  you should be calling WinGetPS/WinReleasPS instead
of WinBeginPaint/WinEndPaint.

 S> I want to make use of this in order to avoid repainting the
 S> complete client area of my terminal type window when text has
 S> to be scrolled upwards.

(Good) WM_PAINT code should always be prepared to paint only the portion of
the window described by the rectangle returned by WinBeginPaint().

To force just a part of your window to be repainted (as is the case with
scrolling),  call WinInvalidateRect() with only the part of the window that
needs to be painted --- this will cause a WM_PAINT message to be sent,  if
required (PM will take into account if all/part of the window is obscured).

In the case of scrolling text,  you should be using WinScrollWindow(),which
will move all of the text for you (no repaint required for smart WM_PAINT
code),  exposing the area where you need to place new text.
WinScrollWindow() will automatically invalidate the naked portion of the
window if you tell it to (no need to call WinInvalidateRect).

The paint rectangle is in device coordinates (pixels);  it is a simple
matter to relate this back to a "line and column" number in your
text,based on the current font size.

Coincidentally,  someone in the fidonet OS2PROG echo was looking for a
sample about the same thing today,  so I released a sample.

FREQ pmtermsr.lzh from 1:259/414,  approx 30k.

--- Maximus/2 3.00