Richedit 2.0 control ignores WParam for WM_PAINT messages?

Question

I've read a lot of issues with trying to double-buffer a richedit control, but have not seen any direct answers to this specific question (would be really great to have a quote/link where Microsoft has an official statement).

Here is some code (VCL/Delphi/Borland Builder 6.0) I've been using for testing:

if(Message.Msg == WM_PAINT)
  {
  HDC dc = GetDC(0);
  HBITMAP memBitmap = CreateCompatibleBitmap(dc,ClientRect.Right,ClientRect.Bottom);
  ReleaseDC(0,dc);
  HBITMAP memDC = CreateCompatibleDC(0);
  HBITMAP oldBitmap = SelectObject(memDC,memBitmap);
  try{
  //PAINTSTRUCT ps;
  //dc = BeginPaint(Handle,&ps);
  dc = GetDC(Handle);
  Message.WParam = (int)memDC;
  inherited::WndProc(Message);
  Message.WParam = 0;
  //BitBlt(dc,0,0,ClientRect.Right,ClientRect.Bottom,memDC,0,0,SRCCOPY);
  ReleaseDC(Handle,dc);
  //EndPaint(Handle,&ps);
  } __finally
     {
     SelectObject(memDC,oldBitmap);
     DeleteDC(memDC);
     DeleteObject(memBitmap);
     }
  return;
  }

If I call BeginPaint() before inherited::WndProc() (that passes the message to the control for those that don't know VCL), then the control does not draw anything on my memory DC or the actual window DC. If I call GetDC() instead, the control still doesn't draw on the memory DC, but then it does draw on the window DC directly. I confirm this by commenting out my BitBlt() call.. if it isn't commented out, the client area is all black (meaning the control didn't paint on the memory DC at all), if I comment out that line, the control draws correctly (meaning it ignroed the WParam memory DC and went directly to the window DC).

While it sounds like I've answered my own question, what I really want is confirmation from others (link to MS KB article or MSDN would be great, so I can show my boss :), AND possible other ideas to achieve double-buffering? I can't use most of the hacks I have found like having the control be hidden off-screen or using WM_PRINT, because I need this control to actually work for user-input and scrollbars, it's not just read-only for display.

Also, the control is using RichEdit 2.0, even though I'm using VCL.. it has been modified to create the window as "richedit20a" class. I have also confirmed that the VCL layer is not messing with the painting at all, so this same behavior should be seen with pure win32 code.

score 4 · Accepted Answer · edited Jun 20 '20 at 09:12

4

what I really want is confirmation from others (link to MS KB article or MSDN would be great, so I can show my boss :)

How about the obvious location: The documentation for the WM_PAINT message, which clearly states

wParam

This parameter is not used.

There is therefore no reason to expect that modifying the wParam will have any effect.

edited Jun 20 '20 at 09:12

Community

1
1

answered Mar 01 '12 at 16:55

Raymond Chen

44,448
11
96
135

Wow, my bad. That's what I get for using the 10 year Win32 docs that came with my 10 year old IDE. I usually look up everything on MSDN, but I guess in this case I just figured something so basic as WM_PAINT would never change... my bad. From the old doc that comes with Borland Builder 6.0: WM_PAINT hdc = (HDC) wParam; // the device context to draw in – eselk Mar 08 '12 at 19:18
That link does say this however, but they don't list which controls support it: "For some common controls, the default WM_PAINT message processing checks the wParam parameter. If wParam is non-NULL, the control assumes that the value is an HDC and paints using that device context." – eselk Mar 08 '12 at 19:32

Richedit 2.0 control ignores WParam for WM_PAINT messages?

1 Answers1