それは越権行為だと思う。
Documentがやるべきことじゃねーですよ。

通常は、ドキュメントクラスの中身を更新するのはViewの役目になると
思いますから、Viewはドキュメントに変化が起こっている事を把握しているはずです。
従ってViewの方で状態を保持する変数の中身を書き換えてそれぞれの項目に対応する
ON_UPDATE_COMMAND_UIのハンドラ関数でEnable/Disableを制御する事になると思います。
ドキュメントクラスしか変更を感知できないような場合はViewに対してドキュメントが
変更された事を通知（CDocument::UpdateAllViews）してView側でドキュメント内の状態を
検査して変更内容に合わせて状態を保持する変数の中身を書き換える事になると思います。

シャノンさんの意見に私も賛成です。
ドキュメントクラスは表示対象のデータ保持とファイルとの入出力が役目なので
ドキュメントクラスに必要以上の機能を入れるのはどうかと思いますね。
ユーザーとのやり取りに関してはヴューやフレームウインドウに任せるべきでしょう。

> ドキュメントクラスは表示対象のデータ保持とファイルとの入出力が役目なので
> ドキュメントクラスに必要以上の機能を入れるのはどうかと思いますね。
> ユーザーとのやり取りに関してはヴューやフレームウインドウに任せるべきでしょう。
原則はその通りと思いますが、ドキュメントに直接関連付けられるコマンドもあるのでは？
例えば、WordやExcelの[ファイル]-[プロパティ]メニューはビューではなく、ドキュメント
に関連付けられているのではないでしょうか？印刷関連のメニューは？
これらもビューやフレームを通して制御すべきですか？

私はコマンドUIをどのクラスから制御するかはそのコマンドの仕様によると考えるので、
画一的にビューやフレームウィンドウに任せるべきとは考えません。
/* でもほとんどのコマンドはビューやフレームから制御しますが... */

> 原則はその通りと思いますが、ドキュメントに直接関連付けられるコマンドもあるのでは？
> 例えば、WordやExcelの[ファイル]-[プロパティ]メニューはビューではなく、ドキュメント
> に関連付けられているのではないでしょうか？印刷関連のメニューは？
> これらもビューやフレームを通して制御すべきですか？

うーん、私自身はユーザーオペレーションに関しては基本的にViewかFrameが受けるべきと
考えていますのでプロパティも印刷もそういう意味ではViewやFrameですね。
ViewやFrameが受けて、ドキュメントクラスに適切な処置をすれば良い訳で
ドキュメントクラスにそれらの設定用の関数を設ける事はしてもそれを使うのは
ViewやFrameだと考えています。

特に印刷に関してはWindowsのWYSIWYGの考え方からすれば、むしろViewで実装すべきと思
います。
印刷用のプロパティにしても内容を保持するのはドキュメントクラスでも良い
（ドキュメント毎に印刷設定を保持したい場合等もあると思うので）と思いますが、
実際の印刷制御はViewがすべきでしょうし、パラメータの受け取りにしてもしかりだと
思います。

> うーん、私自身はユーザーオペレーションに関しては基本的にViewかFrameが受けるべきと
> 考えていますのでプロパティも印刷もそういう意味ではViewやFrameですね。
> ViewやFrameが受けて、ドキュメントクラスに適切な処置をすれば良い訳で
> ドキュメントクラスにそれらの設定用の関数を設ける事はしてもそれを使うのは
> ViewやFrameだと考えています。
それでも私はやはりコマンドの仕様によると考えます。
前にあげたプロパティはドキュメントに直接依存し、ビューには依存しないと考えます。
プロパティを表示するのにViewを経由しなければならないとすると、ドキュメントの新
しい見せ方（新しいView）を追加した場合、そのクラスにもコマンドUIハンドラ、コマ
ンドハンドラを追加しなければ成らなくなります。そして、それは他のViewに書いた処
理と同一（またはドキュメントクラス内の同じ関数の呼び出し）になります。
ドキュメントに依存するコマンドはどのViewでも実行できるべきと考えるので、それは
やはりドキュメントクラスに実装すべきと考えます。

> 特に印刷に関してはWindowsのWYSIWYGの考え方からすれば、むしろViewで実装すべきと思
> います。
これについては同意いたします。

皆さん貴重なご意見,ご指摘ありがとうございます。
まだ実装できていませんが、どのクラスに制御させるべきなのかをよく考え,対応したいと思い
ます。

MFCのMDIの話になってしまうが
確かビューかなんかでメニューの内容を切り替える機能とかあったような。
よく覚えてない。

それとON_UPDATE_COMMAND_UIは
こちらからメニューを有効・無効にするのではなく
有効、無効にするのか聞かれるために呼ばれるものなんだな。

MFCのメニューがそういう仕組みで有効・無効を切り替えるんだから仕方ない。

ビューがドキュメントの状況を必ずしも所持していなくていいと思うけど。
ビューにドキュメントとに関するデータを持つなんて何のためにドキュメントを分離した
んだか。
ビューがドキュメントにこのメニューの機能を実行できる？って訊ねてもいいんじゃない。

ドキュメントがメニューの処理してもいいんじゃね。
たとえば上書き保存 ON_COMMAND(ID_FILE_SAVE, &CDocument::OnFileSave) は、
もう既に多くの人がビューを介さないで
ドキュメントにメニューの処理を行わせる
プログラムを作っている実績があることになる。

フレームとかビューにハンドラがなければ
ドキュメントのON_UPDATE_COMMAND_UIとON_COMMANDが呼ばれるよ。

> ビューがドキュメントにこのメニューの機能を実行できる？って訊ねてもいいんじゃない。

それに関しては私もそう思います。
データを握っているのはドキュメントでデータについてはドキュメントに聞けで良いかと
まあ、細かい実装に関しては皆さんそれぞれの考え方もあると思うので参考にしてもらう
程度で良いのかなとも思いますね。