🚀 go-pugleaf

The processing of messages that cause the screen to be repainted may take
a long time. During that time other messages may arrive, that make the
current repainting of the screen worthless, because they change the screen
and need again a repaint. Such messages may be iconizing, closing or resizing
the window, typing in text by keyborad or drawing graphics by mouse, ...

Therefore it seems reasonable to abort processing of WM_PAINT as soon
as such messages arrive and to process these messages.

In C this seems to me easy. There is probably a function like
"look_for_event_but_don't_get_it()". If it returns such an event,
I close all device contexts, that I opened during WM_PAINT, I invalidate
the part of the window, that has not yet been repainted (in case of doubt
the whole window) and then I return premature from the function that
processes WM_PAINT. Am I right?

How can the same be acomplished in Visual Basic?

Regards, Christian Barmala