Richedit 2.0 control ignores WParam for WM_PAINT messages?

StackOverflow https://stackoverflow.com/questions/9520039

  •  15-11-2019
  •  | 
  •  

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.

Was it helpful?

Solution

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top