> 「ファイルを開く」で画像ファイルを読み込むつどウインドウが増えるように
> 予想していたのですが違いますか？
その場合、増えるのドキュメント-チャイルドフレームのセットではないんでしたっけ。
同じチャイルドフレーム上にビューを増やしていくのではないと思いましたけど。
# 確認していないのであやふや。

どちらかというと、[ウィンドウ]-[新しいウィンドウを開く]メニューの方が心配。
このコマンドは今開いているドキュメントに対して新しいウィンドウを開きますが、
このウィンドウがチャイルドフレームなら問題ないんだけど。

「フレームからＶＩＥＷへ再描画を命令したい」というのが題目だったのすが、「紆余
曲折がありまして、「セパレートで分割した片方のＶＩＥＷからもう片方のＶＩＥＷへ
（ドキュメントを経由せずに）再描画を命令したい」ということに変わりました。で、
これが解決しましたので、コーディングを載せます。maruさん、bunさん、ITOさん、
PATIOさん、はじめご返答いただいたみなさま、ほんとうにありがとうございました。

>ChildFrm.cpp OnCreateClient()

if(!m_wndSplitter.CreateStatic( this,
1, 2,
WS_CHILD | WS_VISIBLE )
) return FALSE;

if(!(m_wndSplitter.CreateView(0,0,RUNTIME_CLASS(CDumpView),
CSize(256,64),pContext))) return FALSE;
if(!(m_wndSplitter.CreateView(0,1,RUNTIME_CLASS(CNekketsuView),
CSize(96,64),pContext))) return FALSE;

m_DumpViewh = (CDumpView *)m_wndSplitter.GetPane(0, 0);
m_NekketsuViewh = (CNekketsuView *)m_wndSplitter.GetPane(0, 1) ;
return(TRUE) ;

>ChildFrm.cpp ２つのあたらしいメソッド
CChildFrame::UpdateDumpView(void)
{
m_DumpViewh->Invalidate() ;//落ちる

}
CChildFrame::UpdateNekketsuView(void)
{
m_NekketsuViewh->Invalidate() ;
}
> ダンプ側から熱血側へ再描画命令
((CChildFrame *)this->GetParentFrame())->UpdateNekketsuView() ;
> 熱血側からダンプ側へ再描画命令
((CChildFrame *)this->GetParentFrame())->UpdateDumpView() ;

>その場合、増えるのドキュメント-チャイルドフレームのセットではないん
>でしたっけ。
>同じチャイルドフレーム上にビューを増やしていくのではないと思いましたけど。
># 確認していないのであやふや。
Viewも一緒だと思ったもので問題になるかなと思ったので。

>どちらかというと、[ウィンドウ]-[新しいウィンドウを開く]メニューの方が心配。
>このコマンドは今開いているドキュメントに対して新しいウィンドウを開きますが、
>このウィンドウがチャイルドフレームなら問題ないんだけど。
なるほど、そこも問題になりそうですね。

> 「ファイルを開く」で画像ファイルを読み込むつどウインドウが増えるように
> 予想していたのですが違いますか？
　そのとおりです。

？？？なんか違います？

> Viewも一緒だと思ったもので問題になるかなと思ったので。
当然ドキュメントに対応してビューも増えるけど、そのビューは新たに生成された
チャイルドフレーム上に置かれるので、問題ないかと。
# だからチャイルドフレームが新たに生成されるかどうかあやふやなんだろ -> 自分

私がしてきた話ですが、設計論的に間違っているという指摘もありますが...
話しても結論が出なさそうなので、
その話は置いておいて、とにかく話通りに作ってみたものです。

良かったら、ダウンロードしてみてください。
http://aventech.hp.infoseek.co.jp/Test.zip

>？？？なんか違います？
ですよね。
個々のウインドウの倍率が変化していますか？

>当然ドキュメントに対応してビューも増えるけど、そのビューは新たに生成された
>チャイルドフレーム上に置かれるので、問題ないかと。
なるほど、そうですか。
リストを見るとそうですね。
今回、CSplitterWndですからね。

bunさん、サンプル作成ご苦労さんです。
確かにウィンドウ毎に倍率を変更出来ていますね。

このアプリで確認してもらえればわかると思うんですけど、一つのドキュメントに
複数のビュー（ここではスプリッタウィンドウで構成されたウィンドウ）を表示さ
せている時（[ウィンドウ]-[新しいウィンドウを開く]メニューを使う）、拡大/縮
小コマンドを実行すると拡大/縮小の対象になっていないウィンドウもUpdate()が
呼び出されます。私はこれが冗長、無駄だといっているんです。
このプログラムでは描画が短時間で終わっているため、特に問題ありませんが、
Update()に時間がかかるようなプログラムでは問題になります。だから更新対象の
ビューに特定して処理すべきだと言っています。

もちろん、一つのドキュメントに対して一つのウィンドウ（ビュー）した割り当てな
いというのであれば、問題は有りません。

ようやく、脳みそが整理されてきました。
複数ビューの意味にも大きく２種類あるのではということです。

複数ビューが、
ビュ－クラス１つ → ビューオブジェクト複数
なら、maruさんの話通り。

ただし、今回は、
ビュ－クラス１つ → ビューオブジェクト１つ
で、ビュークラス自体が複数あるから複数ビューに見えるだけです。

こういうものって、実は多いです。
一番身近なのはエクスプローラ。
ツリービューとリストビューの複数ビューありますが、ツリービュー自身が複数
になったり、リストビュー自身が複数になることはありません。

この場合にカレントフォルダの選択が変わったとしたらどうでしょう。
ドキュメントは変わってませんよね。
フォルダもファイルも全くいじくってないですからね。

でも、そういう場合に、
例えば、ツリービュー側でカレントフォルダが変更されたら、
UpdateAllViews(this, ...); // thisはツリービューのポインタ
としてリストビュー側に伝えるのは良くあるサンプルコードのような気がします。
今回は、まさしく同じパターンかなと。

う～ん、やはり、何か間違ってるのかなぁ？

>う～ん、やはり、何か間違ってるのかなぁ？
うーーん、
maruさんの話は、
　「　描画時間がかからない場合は、一つ描画するのも十描画するのも一緒ですが、
　時間がかかる場合は待っているほうが辛くなります。また他の処理に問題が起こる
　場合もありえます。
　　　なので、今回のような場合は最初から「UpdateAllViews」を使わないで考えた
　方がいいと思います。」
というような解釈でいますがどうですか？
　　
> でも、そういう場合に、
> 例えば、ツリービュー側でカレントフォルダが変更されたら、
> UpdateAllViews(this, ...); // thisはツリービューのポインタ
> としてリストビュー側に伝えるのは良くあるサンプルコードのような気がします。
描画に時間がかからず、他の処理に問題が起こらないことが分かっているなら
いいと思います。

今回の場合、どれだけ描画に時間がかかるかこちらもわかっていませんね。

繰り返しになりますが、
> UpdateAllViews()で全てのViewを更新するのが最も簡単な方法であることもわかって
> いますが、その副作用についても考察してください
ということです。

> ただし、今回は、
> ビュ－クラス１つ → ビューオブジェクト１つ
> で、ビュークラス自体が複数あるから複数ビューに見えるだけです。
これが勘違いでは？

あなたの作成したアプリでも
> ビュ－クラス１つ → ビューオブジェクト複数
は既に実現されているんですよ。理解していますか？
試しに[ウィンドウ]-[新しいウィンドウを開く]メニューを実行してみてください。

> う～ん、やはり、何か間違ってるのかなぁ？
あなたの考えが間違っているということではなく、今回の場合、UpdateAllViews()
を使うのは余り適切とは思えない、という意見を言ってるんです。

ITOさん、行間を読んでいただき恐縮です。その通りです。

う～ん、みなさんの話は全て理解できていると思います。
----------------------------------------------------------------------
>あなたの作成したアプリでも
>> ビュ－クラス１つ → ビューオブジェクト複数
>は既に実現されているんですよ。理解していますか？
理解しています。
あくまで、私の話はドキュメント１つに対するビューの話です。

> 試しに[ウィンドウ]-[新しいウィンドウを開く]メニューを実行してみてください。
をした瞬間、２つめのドキュメントが起動するので、別の話になります。

> あなたの考えが間違っているということではなく、今回の場合、UpdateAllViews()
> を使うのは余り適切とは思えない、という意見を言ってるんです。
バグがあるとか設計不良とかそういう間違いを心配しているわけではありません。
ただ、私自身の考え方に無理(それを自分自身に対して間違いと表現させていただいて
います)があるなら知っておきたいのです。
----------------------------------------------------------------------

その上で、どうにも納得がいきません。
納得いかないのは、さっきの話です。

ツリービューとリストビューをもつサンプルは世の中にあふれていて、
そういうサンプルでは、ドキュメントの更新なし(ツリーの選択が変わったなど)で、
ツリービューの選択を、
UpdateAllViews(this, ...); // thisはツリービューのポインタ
伝えています。

ドキュメントが変わっていないのに、
CDocument::UpdateAllViews()
というドキュメントクラスのメンバが呼ばれています。

私の考えでは今回のサンプルと、
上記のツリービューとリストビューをもつサンプルは同じなのです。

もし私の考えが間違っているとすると、そこが間違いくさいのですが、
頭が悪いのか私には違いが分かりません。

すいませんが、分かりやすく教えていただけますでしょうか。

> > 試しに[ウィンドウ]-[新しいウィンドウを開く]メニューを実行してみてください。
> をした瞬間、２つめのドキュメントが起動するので、別の話になります。
これが間違いの元。
このコマンドは同一のドキュメントに対して別のウィンドウを開きます。
別のドキュメントであればUpdateAllViews()でCTestView::OnUpdate()は一回しか呼
び出されないはずですが、あなたのアプリではウィンドウの数だけ呼び出されます。

[ファイル]-[新規作成]ではあなたの言うとおり二つめのドキュメントを作成しする
ので、UpdateAllViews()をやってもCTestView::OnUpdate()はそのドキュメントに関
連するViewの数だけになります。

> ツリービューとリストビューをもつサンプルは世の中にあふれていて、
> そういうサンプルでは、ドキュメントの更新なし(ツリーの選択が変わったなど)で、
> ツリービューの選択を、
> UpdateAllViews(this, ...); // thisはツリービューのポインタ
> 伝えています。
サンプルはあくまでサンプルで本当のそのようなビューを持つアプリケーションが
UpdateAllViews()を使っている証拠がどこに有りますか？
そのようなアプリケーションは私の指摘している問題点がないんですか？