まったくしょうもないバグをほってありますよね。
詳しくは書きませんが、MDI子ウインドウがWM_NCPAINTを正しく
処理できない仕組みになっているのが原因だと思われます。

対症療法しかありませんが、自分の場合は
　１．当該ウインドウのWM_PAINT=OnPaint()をオーバーライドする
　２．OnPaint()内でGetWindowLongPtr()を使用してスタイルを取得し、それが
　３．(WS_HSCROLL | WS_VSCROLL)スタイルを含むのなら
　　　３．１　当該ウインドウのサイズYを1増やしてSetwindowPos()する
　　　３．２　サイズYを元に戻してSetwindowPos()する
　４．派生元のOnPaint()処理を行う

でやってます。

ちなみに、OnNcPaint()をオーバーライドしてがんばっても、
多分徒労に終わると思います。

あと、SetwindowPos()で使う座標は親のクライアント座標なので
GetWindowRect()とScreenToClient()を使って何とかしてください。

仲澤＠失業者様、ありがとうございます。

早速試してみまして、たしかに解消されることを確認しました。

しかし自分のアプリケーションがドキュメント－ビュウを使用しているためか
OnPaintで処理しますと画面が表示されず、また子ウィンドの書き換えを延々と
行うらしくＣＰＵ使用率が１００％にはりつきます。
下記のソフトにて試したのですが、これで指摘していただいた通りの動きに
なるのでしょうか？
void CMyView::OnPaint()
{
CPaintDC dc(this); // device context for painting
// TODO: ここにメッセージ ハンドラ コードを追加します。
// 描画メッセージで CView::OnPaint() を呼び出さないでください。

RECT tRect;

this->GetWindowRect( &tRect );
this->ScreenToClient( &tRect );
this->SetWindowPos( NULL, tRect.left,
tRect.top,
tRect.right-tRect.left,
tRect.bottom-tRect.top+1,
SWP_NOZORDER );

this->SetWindowPos( NULL, tRect.left,
tRect.top,
tRect.right-tRect.left,
tRect.bottom-tRect.top+1,
SWP_NOZORDER );
}

＞＞まったくしょうもないバグをほってありますよね。

古くからあるバグなのでしょうか。
ためしにVisual C++ Ver6.0でもやってみましたが同じ症状を確認しました。
また、Visual Studio2005付属のSpy++アプリケーションでも同様の現象が
発生することを確認しました。
Exel2000ではアクティブでないウィンドのスクロールバーを消してますね。

＞＞ちなみに、OnNcPaint()をオーバーライドしてがんばっても

これも試してみましたが、やはり徒労に終わりました。

うーーん
　僕なら、「CFormView」を選択しますね。

　１．PictureControlで適当なグラフ画面を作成する。
　２．PictureControにグラフ画面を直接描画する。
　３．専用のX,Yのスクロールバーを置く。
　４．OnHScroll()、OnVScroll()を使って移動量を設定する。
　５．場合によっては、Invalidate();
６．OnDraw()内で、スクロールの移動量に合わせたグラフ描画を行なう。

の手順で行ないますね。

>OnPaintで処理しますと画面が表示されず、また子ウィンドの書き換えを延々と
>行うらしくＣＰＵ使用率が１００％にはりつきます。

OnPaint()で当該の処理を行う場合に、再入禁止フラグを
用意して、再入しないようにしましょう。
OnSize()で、Invalidate() Update()をしている場合も
当該フラグで重複した処理をしないようにしてみてください。
これでもだめな場合、WM_WINDOWPOSCHANGEDをオーバーライドして、
何も処理しない(基本クラスを呼ばない)にしてみてください。

おっと、ソースもちょっと変かな。

if( FALSE == m_DontReEntrant ){ // 再入禁止でないなら
m_DontReEntrant = TRUE;　　　// 再入を禁止
　　GetWindowRect( &tRect );
GetParent()->ScreenToClient( &tRect ); // ここは親のHWNDで
this->SetWindowPos( NULL, tRect.left,
tRect.top,
tRect.right-tRect.left,
tRect.bottom-tRect.top+1,
SWP_NOZORDER );

this->SetWindowPos( NULL, tRect.left,
tRect.top,
tRect.right-tRect.left,
tRect.bottom-tRect.top, // ここは元に戻す
SWP_NOZORDER );
m_DontReEntrant = FALSE;　　　// 再入を許可
}

もしかしてこの現象ってシステムレベルのバグ？

MFCの使用/不使用やSDI/MDIに関係無く
・Window に WS_HSCROLL | WS_VSCROLL が指定
・WindowsXP で テーマが適用されている
で発生してる感じがする。

幾つかのフリーソフトでも発生してたし、エクスプローラでも症状が出てた。
ちなみに、同exeを Vista（x64）環境で実行しても症状は起きなかった。

露見し難いワケでも無く修正されていても良いバグだと思うけど…何で放置されているん
だろう？

単に、右隅のポツポツした「グリップ」様のものを描画し忘れている
だけなんですけど、この部分は

　１．単にボタン背景色で塗りつぶす
　２．斜線で表現した「グリップ」様にする
　３．ポツポツで表現した「グリップ」様にする

等のバージョンがあり、３．で描画し忘れが発生するようです。
私見ですが、コモンコントロール由来であることが疑われます。

仲澤＠失業者様　回答ありがとうございます。
ソースを修正してみましたが、現状でも画面書き換えを延々と
行ってしまいます。
再入をしているのかトレースしてみましたが

トレース１
if( FALSE == m_DontReEntrant ){
トレース２
m_DontReEntrant = TRUE;
　　GetWindowRect( &tRect );
GetParent()->ScreenToClient( &tRect );
this->SetWindowPos( NULL, tRect.left,
tRect.top,
tRect.right-tRect.left,
tRect.bottom-tRect.top+1,
SWP_NOZORDER );

this->SetWindowPos( NULL, tRect.left,
tRect.top,
tRect.right-tRect.left,
tRect.bottom-tRect.top,
SWP_NOZORDER );
m_DontReEntrant = FALSE;
}
トレース３

上記”トレース”の部分でログをファイルに書き出して調べまして
トレース１→トレース２→トレース３の順番で実行されていることを
確認しましたので、再入は起こっていないのかと思われます。
また、WM_WINDOWPOSCHANGEDをオーバーライドして基本クラスの呼び出しを
コメントアウトしましたが効果がありませんでした。
もう少し色々と調べてみます。

ITO様　回答ありがとうございます。
CFormViewはCScrollViewの派生クラスみたいですね。
サンプルScribbleを試したところ、CScrollViewを子ウィンドにしたＭＤＩ
アプリケーションではこの異常が発生しないので、CFormViewでも発生
しないかもしれませんね。

gak様　回答ありがとうございます。
＞＞ちなみに、同exeを Vista（x64）環境で実行しても症状は起きなかった。
興味深いですね。
こちらでもVista(32bit)や7(32bit)でどうなるか後ほど試してみたいと思います。

SDK版のMultiPadでは発生していませんでした(BC5添付のMS謹製のサンプル)。
MDIFrameとMDIChildFrameで
WNDCLASSのhbrBackground=(HBRUSH)(COLOR_WINDOW + 1)を指定し、
CreateWindowのdwStyleにWS_CLIPCHILDRENを含めない
となっていました。

ただし、MDIChildのグリップ部分はイポなしのフラットになる場合があります。
ちらつきも多いです。

憶測ですが、
WM_NCPAINTはグリップ部分の描画を親ウィンドウに任せる場合があるようです。

WM_NCPAINTで出来るようなのですが。

VC6付属のMFC版MultipadでCEditViewを継承して、以下追加。

void CMyEditView::OnNcPaint()
{
HDC hdc = ::GetWindowDC(*this);//クリップを無視しています。
RECT rc;
::GetClientRect(*this, &rc);
rc.left = rc.right;　// エッヂ幅を無視しています。少しごみが残ります。
rc.top = rc.bottom;
rc.right += GetSystemMetrics(SM_CXVSCROLL);
rc.bottom += GetSystemMetrics(SM_CYHSCROLL);
// themeは無視していますので、斜め線のグリップになります
DrawFrameControl(hdc, &rc, DFC_SCROLL, DFCS_SCROLLSIZEGRIP);

CEditView::OnNcPaint();
}

ロマさま　返信ありがとうございます。
Multipadサンプルを探すことができませんでした。
VC6のサンプルのどのあたりにあるのでしょうか？
教えていただけませんでしょうか。

色々と試してみたのですが、まずWS_HSCROLL | WS_VSCROLL を
指定したMDI子ウィンドでもWindows2000やWindows7(32bit)で
試したところ、この現象は起きませんでした。

また、スクロールバーをOnUpdate()で
　CView::ShowScrollBar( SB_BOTH );
を呼び出して表示させた場合はこの現象は起きません。
ただし、CView::SetScrollInfo()でパラメータを
設定すると、現象が再び発生します。

CScrollViewクラスのサンプルScribbleではこの現象が発生しないため
CScrollViewがどのようにしてスクロールバーを表示しているのか
知りたいと考えてソースを追いかけていますが、どなたか情報をお持ちの
かたがおりましたら教えてください。

MSDNライブラリMicrosoft Visual Studio 6.0の検索からMultipadは探せると思うんです
が。
cdのsamples\vc98\mfc\general\multipadです。

> また、スクロールバーをOnUpdate()で
> 　CView::ShowScrollBar( SB_BOTH );
> を呼び出して表示させた場合はこの現象は起きません。

これはおもしろいですね。

> CScrollViewクラスのサンプルScribbleではこの現象が発生しないため

Scribble step7のスクロールバーとグリップハンドルはコントロールです。
Spy++で確認願います。

私の調査結果を報告します。

1)誰が非クライアント領域を描画するのか
　WM_NCPAINT以外にもWM_NCACTIVATEが描く。
　タイトル部分は、WM_SETTEXTも。

2)GetDCEx
　WM_NCPAINT内では、GetWindowDC()の方が簡単。
　GetDCExを使う場合は謎のフラグが必要らしい(DCX_USESTYLE?)。

3)リージョン
　WM_NCPAINTの(wParam > 1)の場合、wParamはクリップリージョン。
　このリージョンはスクリーン座標系、GetWindowDC()はウィンドウ座標系。

4)クラシックスタイル
　* manifest付きでも、ShowScrollBar()でスクロールバーを表示すると
　 クラシックスタイルになる。
* WM_NCACTIVATE内でSendMessage(WM_NCPAINT)すると、クラシックスタイルになる。
　この２点は謎です。　

参考)　C++ Q & A -- Microsoft Systems Journal January 1997