ＳＰＹ＋＋って知ってる、あなたのやりたい行為をスパイしてみて飛んでくる
ＷＭメッセージを処理してあげればいいんじゃないの？
クラスウィザード使えばわかると思うけど「ＷＭ＿？？？」は関数「Ｏｎ？？？」になるはず
です

>PreTranslateMessage関数の中でキー検知して、飛ばした先でDoModal()した
>直後は、オーバーライド元？へ通してはまずいのですね？

（１）
アサートの問題はさておき、このような処理手順であれば DoModal() 後は
return TRUE; で処理を終えるのが普通でしょう。
ダイアログを表示するきっかけになったキー入力を、DoModal() 後に継続して
デフォルト処理したい場面なんてほとんどありえないと思います。
＃大昔のキー入力をいまさら思い出してどうする、ってなものです。
この処理手順では return TRUE; で抜けるのは、アサート防止のためなどではなく、
そうするのが当たり前なので、そうしてください。

＃KeyChangeProcess()という関数を実行するケースもあるようですが、
＃こちらは関数名から想像するに、別のキー入力に変換するのが目的ですね？
＃その場合は、逆に、デフォルトの処理に通すのが当然、てことになります。

（２）
さて、上記とは別になぜアサートに至ってしまうのか？ってことですが、
どうやら PreTranslateMessage で渡される pMsg の先にあるメッセージ
データが DoModal() の前後で書き換わってしまうことが原因のようです。
たぶん、DoModal() 内でキューから取り出した最新のメッセージに
置き換わっています（このメッセージは既に DoModal() 内で処理済のはずです）。
なので、DoModal() 後に継続して処理させようとすれば、処理矛盾が生じるのは
当然のことです。
おそらく MFC の設計者は、（１）のような理由から、メッセージループを別途
回すようなことをするなら pMsg の先のデータは置き換わってしまっても構わない
と考えたのでしょう。

あと、PreTranslateMessage の使い方についてですが、
私は別の方法で可能ならば、PreTranslateMessage を使わずに済ませるように
したほうがいいと思います。
しかし、それではどうにもならない場合もあります。
例ではフォームビューでこれを使っているようなので、Tab のような特別なキーも
拾いたいなら PreTranslateMessage でないと拾えないです。
＃特別なキー入力は PreTranslateMessage を抜けたらキー入力とは別の処理に
＃変換されてしまいますからね

> OnkeyDown関数は、フォームビューにコントロールを配置して
> それらがフォーカスを持つと効かない

確かにフォームビューだとキーストロークのメッセージはビューのOn...ハンドラを呼び
出さないようになっていますね．
失礼しました．

psz様

今の自分ではまだ突き止められないような部分まで明らかにして下さいまして
本当に勉強になりました。ありがとうございました。
やはり無駄な、無意味な処理の流れを入れていると問題も起きやすいということ
なのでしょうね？^^;良い経験でもありました。
所々で「当たり前」「当然」と言われまして、ちょっぴりズキッとしましたが（笑）
これからもっと洗練されたコードを書けるようにも頑張っていきたいと思います。

wood様

いろいろ便利なツールを使いこなしてのデバッグ手順等、ご指導頂いても
戸惑ってしまう自分の苦手としている部分を改めてわからせても下さいまして
ありがとうございます。今後、いろんなデバッグ技術も習得して効率良く
作成できるよう頑張りたいと思います。

monkey様

＞確かにフォームビューだとキーストロークのメッセージはOn...ハンドラを呼び
＞出さないようになっていますね．
＞失礼しました．

とんでもございません。自分でそういうことを調べられて、そういう表現できるまでに
なれるよう先ず頑張りたいと思います。^^;

皆様、この度はお忙しい中ご助言ご指導下さいまして、本当にありがとうございました。
また何かお気付きになられました時には宜しくお願い致します。

うっかりしてました。^^;解決マークもチェックしておきます。