trier@cwlim.INS.CWRU.Edu (Stephen C. Trier) (05/26/91)
I'm a little confused by the "Comments" section of the PeekMessage entry in the SDK Reference Volume 1, page 4-330. It states, "PeekMessage does not remove WM_PAINT messages from the queue. The messages remain in the queue until processed." Does "processed" refer to the BeginPaint function, or is there something else I need to do when using PeekMessage? Thanks. -- Stephen Trier Work: trier@ins.cwru.edu Case Western Reserve University Home: sct@seldon.clv.oh.us Information Network Services
kentfo@polari.UUCP (Kent Forschmiedt) (05/27/91)
In article <1991May26.084935.14400@usenet.ins.cwru.edu> trier@po.CWRU.Edu writes: >I'm a little confused by the "Comments" section of the PeekMessage entry >in the SDK Reference Volume 1, page 4-330. It states, "PeekMessage does >not remove WM_PAINT messages from the queue. The messages remain in the >queue until processed." Does "processed" refer to the BeginPaint function, >or is there something else I need to do when using PeekMessage? From ValidateRect in the SDK Reference: "Windows continues to generate WM_PAINT messages until the current update region is validated." Neither PeekMessage nor GetMessage "removes" WM_PAINT messages from the queue. WM_PAINT is generated when a window has a non-NULL update region and there are no messages on the window's queue. (Is that true, or can it be generated when certain messages are pending?) Anyway, the behaviour is the same whether you got the message with Peek or Get, or even if you never retrieved the message at all. The update region may be retrieved with GetUpdateRect() or GetUpdateRgn(). BeginPaint(hwnd, &ps) does GetUpdateRect(hwnd, lpps->rcPaint, bErase) for you. (If somebody knows where the bErase flag (from the Invalidate{Rect,Rgn} call) is stashed, I'd like to know.) ValidateRect or ValidateRgn must be used to validate the update region. EndPaint(hwnd, &ps) does a ValidateRect(hwnd, lpps->rcPaint). -- Kent Forschmiedt ... kentfo@polari ... uw-beaver!sumax!polari!kentfo
press@venice.SEDD.TRW.COM (Barry Press) (05/28/91)
In article <1991May26.084935.14400@usenet.ins.cwru.edu> trier@po.CWRU.Edu writes: >I'm a little confused by the "Comments" section of the PeekMessage entry >in the SDK Reference Volume 1, page 4-330. It states, "PeekMessage does >not remove WM_PAINT messages from the queue. The messages remain in the >queue until processed." Does "processed" refer to the BeginPaint function, >or is there something else I need to do when using PeekMessage? This is by now a legendary red herring, and should be bronzed, if not in the FAQ. What it says is literally true -- PeekMessage does not remove WM_PAINT from the queue. What it doesn't say is that GetMessage doesn't either. What you followed with is exactly correct -- regardless of how you get your hands on the WM_PAINT, it remains in the queue until the BeginPaint/EndPaint or until you do a ValidateRect of the invalid area. -- Barry Press Internet: press@venice.sedd.trw.com
Barry.Press@sunbrk.FidoNet.Org (Barry Press) (05/28/91)
Reply-To: press@venice.sedd.trw.com (Barry Press) In article <1991May26.084935.14400@usenet.ins.cwru.edu> trier@po.CWRU.Edu writes: >I'm a little confused by the "Comments" section of the PeekMessage entry >in the SDK Reference Volume 1, page 4-330. It states, "PeekMessage does >not remove WM_PAINT messages from the queue. The messages remain in the >queue until processed." Does "processed" refer to the BeginPaint function, >or is there something else I need to do when using PeekMessage? This is by now a legendary red herring, and should be bronzed, if not in the FAQ. What it says is literally true -- PeekMessage does not remove WM_PAINT from the queue. What it doesn't say is that GetMessage doesn't either. What you followed with is exactly correct -- regardless of how you get your hands on the WM_PAINT, it remains in the queue until the BeginPaint/EndPaint or until you do a ValidateRect of the invalid area. -- Barry Press Internet: press@venice.sedd.trw.com * Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0)
kentfo@polari.UUCP (Kent Forschmiedt) (05/30/91)
In article <675404430.40@sunbrk.FidoNet> Kent.Forschmiedt@sunbrk.FidoNet.Org (Kent Forschmiedt) writes: > [ and so forth ] > * Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0) Well, no, I didn't post it from the Fidonet... Perhaps Seaeast should look into this. I hope it doesn't get in the habit of reposting every article that appears in this group. -- Kent Forschmiedt ... kentfo@polari ... uw-beaver!sumax!polari!kentfo