コントロール内に絵を書こうとするとダイアログ全体まではみ出してしまうのはなんでや？

• If you use the CS_PARENTDC style for a class, each window in that class uses its parent window's display context. CS_PARENTDC is similar to CS_CLASSDC in that multiple windows share one display context. In CS_PARENTDC, however, the windows that share the display context need not belong to the same class. All standard Window controls have the CS_PARENTDC style. Thus, an edit control and list box in a dialog box share the same display context—that of the dialog box itself. The benefits of CS_PARENTDC can be summed up with one word: speed. Windows keeps five common display contexts in memory (see the next paragraph). When a window (for example, a dialog box) has more than five child windows (let's say it has six edit controls), the display context cache loses its effectiveness. For each child window, the application must reinitialize a display context with the clipping region and device origin. If the child windows share their parent's display context, the display context will be found in the cache more often. This saves a lot of time and is why standard Windows controls use CS_PARENTDC. Another outcome of the CS_PARENTDC style is that child windows can draw anywhere in their parent's client area as well as drawing in their own client area. The CTL3D library, which creates 3-D effects around edit controls and list boxes, relies on this behavior. An application should not use CS_PARENTDC if it needs to adjust the mapping modes for different child windows. This will negate much of the benefit and could cause problems ensuring that each child window has the correct mapping mode set.

親ウィンドウのクリッピング枠を子ウィンドウが引き継ぐ、と。高速化と立体的なボタンを書くため必要なんだそうな。わからんくはないけど・・・(;;
で対応策はこんな感じ。

void CHogeControl::OnPaint() 

{

    CPaintDC dc(this);
    RECT rc;

    GetClientRect(&rc);

    dc.IntersectClipRect(&rc);
    ...

}