Filling the client rectangle in WM_ERASEBKGND hadler not effective.

If you want black background try this:

BEGIN_MESSAGE_MAP(CMDIPanesView, CView)

ON_WM_ERASEBKGND()

ON_WM_PAINT()

END_MESSAGE_MAP()

BOOL CMDIPanesView::OnEraseBkgnd(CDC* pDC)

{

return TRUE;

}

void CMDIPanesView::OnPaint()

{

CPaintDC dc(this); // device context for painting

dc.FillSolidRect(CXTPClientRect(this), 0);

}

Oleg,

Thank you for the reply. Unfortunately, this problem is occuring in your own sample, which already contains the above code.

Take the unmodified MDI Frames sample, and add the following handler in the CMDIPanesView class:

BOOL CMDIPanesView::OnEraseBkgnd(CDC* pDC)
{
CRect Client;
CBrush BlackBrush(RGB(0,0,0));
   Sleep(250); // Sleep so we can see the bug easily.
   GetClientRect(Client);
   pDC->FillRect(Client, &BlackBrush); // fill with black
   return TRUE;
}

Start the sample. The properties pane is showing on the left. Drag that pane to the bottom of the child window so it docks there. Click the "Auto Hide" pushpin button. The pane closes.

Now, hover over the properties tab on the bottom of the child window. The properties pane pops up without any problem. Move the mouse away so the pane returns to a docked state.

- this is where the bug occurs ---> Hover the mouse over the properties tab a second time. You should see the frame drawn erraneously on the top part of the child window for about 1/4 second (from the Sleep() call above). It is then erased by the EraseBkgnd FillRect() call. Subsequent opening of the properties tab repeats the bug every time. I have no idea why it seems to work the first time and fail every other time.

It is important to note that the OnEraseBkgnd handler above only accentuates the problem -- the bug is there in the unmodified program, it is just harder to see. I believe it's often hidden by the monitor refresh (or lack thereof) although playing with the refresh rate and different resolutions didn't really have much effect.

Also, it seems to occur no matter which side of the child window you dock the panel to. It is easiest to see when docked at the bottom, but is also quite visible when docked on the left or right side.

Another thing I should mention is that when the pane area gets bigger, the problem is more noticeable, as one would expect since it is drawing a bigger rectangle.

Try it and let me know what you think.

Thanks very much,

Tim Ardoin

Developer, Regal Decision Systems, Inc.

Try to add this in yourCChildFrame.

BOOL CChildFrame::PreCreateWindow(CREATESTRUCT& cs)
{
 // TODO: Modify the Window class or styles here by modifying
 //  the CREATESTRUCT cs

 if( !CMDIChildWnd::PreCreateWindow(cs) )
  return FALSE;

 cs.style |= WS_CLIPCHILDREN|WS_CLIPSIBLINGS;

 return TRUE;
}

Hi there,

We've been debugging a graphics glitch in our app. When we hover the mouse over a tab on the bottom of the MDI Child window, there is a flash on the top of the window right before the pane starts to "expand".

After we thoroughly checked our own code, we had a look at the MDIPanes sample program. To our surprise, it does the same thing. It is much less noticeable as it is a light-colored flash on a white background, but it is there. Our App uses a black background and a larger pane, causing this to be a pretty bright, very noticeable flash.

I've enclosed a screenshot of this problem (from the MDIPanes sample) that I was able to take by doing nothing for the WM_ERASEBKGND messages (after a few initial fills to black) in CMDIPanesView, and hovering the mouse over the "properties" tab. It seems to happen every time, although in real time I believe the monitor refresh behavior frequently hides it.

Is there something we can do to fix this on this end, or is this something you will have to do?

We are using XTSuite 8.6 (problem exists on 8510 as well), and Visual Studio 2003. The problem is the same on both W2K and XP.

Here's the Screenshot, it will probably explain what I'm talking about better than I have ;)

Thanks for your help!

Tim Ardoin