9年前メッセージループにIsDialogMessageをかますとENTERキーでボタンを押すことができます。フォーカスの移動とかも自動でやってくれますしダイアログでなくても使えます。9年前>>ISLeさん、ありがとうございます。IsDIalogMessageの存在はTABキーの移動の制御をしたかったので使おうと思ってたんですが、ボタンコントロール以外に、エディットコントロールもあり、そいつもIsDIalogMessageで処理されてしまうため、エディットボックス内のテキスト入力の操作がおかしくなってしまい、断念しました。if(!IsDialogMessage(親HWND,&msg){TranslateMessage(&msg);DispatchMessage(&msg);}通常↑のように処理すると思うのですが、これだとエディットボックスの処理もIdDialogMessageとして処理されてしまうようです。エディットボックスだけ除外できるような方法があればいいんですけどね。07:38追記:上記のような理由からTABキーの移動もサブクラス化にて対応しております。9年前サブクラス化にて使用しているウィンドウプロシージャは下記のコードです。WM_KEYDOWNメッセージが発生したら、ウィンドウハンドルを調べて、ボタンコントロールのウィンドウハンドルであれば、そのウィンドウハンドルにBM_CLICKメッセージを投げて、ボタンを押下させるという仕組みです。下記のようにウィンドウハンドルをチェックして、移動させたいウィンドウハンドルへSetFocusへ移動させてるという単純なものです。CallWindowProc(childedit_proc,hwnd,msg,wp,lp);}}で、ボタンを押下したときの処理としては、下記のようになっています。ボタンをクリックしたときは、WM_COMMANDメッセージが発生するので、WPARAMの下位ワードにある子ウィンドウIDを調べ、そのボタンに応じた処理をそれぞれさせてるという単純なものです。}ですが、ボタンにカーソルを置いて、エンターキーを押してもクリックしたことにはならず、WM_COMMANDが発生しないため、サブクラス化にて対応し、WM_KEYDOWNのメッセージを受け取り対応しているという状況です。何かほかに良い方法はございますでしょうか?なければそのままスルーで結構です。コントロール側のウィンドウプロシージャで処理します。返せば、ダイアログ側は何もしなかった.........はずです。未確認ですがSendMessage(hwnd,BM_CLICK,NULL,NULL)をPostMessageにすれば効きそうな気がします。言え、IsDialogMessageをかましておかしくなるならおかしくなるほうを対処するのが良いと思うのです。標準コントロールを使いつつ標準のUIから外れたことをしようとするとあとからあとから問題が噴出してたくさんの時間を無駄にすることになると思います。9年前>>chemoさんありがとうございますWM_GETDLGCODEですかこれは知らなかったですね。今日帰ったらちょっと調べてみます。>>ISLeさん、ありがとうございます。帰ったらちょっとやってみますね。ISLeさんのおっしゃるとおり、IsDialogMessageにしたほうが仕組みがすごい簡単で後から困らなさそうですよね。IsDialogMessageを使って対処し、その不具合を解決していく方向で進めてまりいたいと思います。今日帰ったら、実際のコードと、その不具合をまた報告しにきます。9年前IsDialogMessageを使用した方法での結果をお伝えします。下記のようにボタンとエディットボックスコントロールを作成しています。BS_DEFPUSHBUTTON,600,662,100,37,hwnd,(HMENU)CHILD_SHUTDOWN,hInstance,NULL);で、IsDialogMessageで処理してるメッセージループは下記の通りです。タブキーでのフォーカスの移動がエディットボックス→ボタンへ移動する時のみ、タブキーを押しても移動してくれません。ウィンドウスタイルでES_MULTILINEを適用していても、エディットボックス内での複数行の入力が出来なくなってしまいます。エディットボックスの全ての処理が、IsDialogMessageで処理されてしまっているのが原因と思われるのですが、これを回避する方法はございますでしょうか?分かる方、ご回答よろしくお願い致します。タブキーでのフォーカスの移動がエディットボックス→ボタンへ移動する時のみ、タブキーを押しても移動してくれません。ウィンドウスタイルでES_MULTILINEを適用していても、エディットボックス内での複数行の入力が出来なくなってしまいます。メッセージループにIsDialogMessageをかませるだけでは実装が不十分でした。ウインドウプロシージャの最後でDefWindowProcの代わりにDefDlgProcを呼び出すようにしてください。ウインドウクラスの登録時、WNDCLASS::cbWndExtraにDLGWINDOWEXTRA(定数)が必要です。以上でES_MULTILINEスタイルのテキストボックスからフォーカスが移動するようになるはずです。DefDlgProcの副作用でクライアント領域背景がダイアログカラーで塗り潰されてしまいます。WM_CTLCOLORDLGメッセージに対して塗り潰しに使う背景ブラシを指定するかWM_ERASEBKGNDメッセージを処理してください。複数行テキストボックスの改行はデフォルトではCtrl+RETURNです。RETURNキーはデフォルトボタンを押す操作になります。RETURNキーだけで改行できるようにするにはES_WANTRETURNスタイルを指定してください。自分の説明が悪かったですかね。使用するはずなんですよね。メッセージハンドラを実装するにはコントロールをサブクラス化する必要がありますね。タブキーでのフォーカスの移動がエディットボックス→ボタンへ移動する時のみ、タブキーを押しても移動してくれません。ウィンドウスタイルでES_MULTILINEを適用していても、エディットボックス内での複数行の入力が出来なくなってしまいます。メッセージループにIsDialogMessageをかませるだけでは実装が不十分でした。ウインドウプロシージャの最後でDefWindowProcの代わりにDefDlgProcを呼び出すようにしてください。ウインドウクラスの登録時、WNDCLASS::cbWndExtraにDLGWINDOWEXTRA(定数)が必要です。以上でES_MULTILINEスタイルのテキストボックスからフォーカスが移動するようになるはずです。DefDlgProcの副作用でクライアント領域背景がダイアログカラーで塗り潰されてしまいます。WM_CTLCOLORDLGメッセージに対して塗り潰しに使う背景ブラシを指定するかWM_ERASEBKGNDメッセージを処理してください。複数行テキストボックスの改行はデフォルトではCtrl+RETURNです。RETURNキーはデフォルトボタンを押す操作になります。RETURNキーだけで改行できるようにするにはES_WANTRETURNスタイルを指定してください。>>ISLeさん!本当にありがとうございます!教えていただいた方法でやってみたところ、タブキーでの移動、テキストボックス内での改行の処理も、ボタンのエンターキーでの押下も問題なく処理できました!ここまでは完璧だったんですが、なぜか右上の×で終了しようとすると、なぜか終了してくれませんでした。今までは右上の×を押すだけで、恐らくDefWindowProcがウィンドウの終了処理をしてくれたんだと思うのですが、DefDlgProcではウィンドウの終了処理をしてくれないのでしょうか?右上の×を押すとメッセージ的には、WM_CLOSEは発生しているようなのですが、どうもDefDlgProcがちゃんと終了処理してくれないようです。その後にWM_COMMANDが発生して、WPARAMの下位ワードに2が入っていたため、あるボタンの処理が実行されてしまうというおかしな状況が発生しました(笑)なので、WM_CLOSEを直接処理するようにし、そこでDestroyWindowを実行して対処しています。これぐらいなら、問題ない範囲なのでまあよいのですが、もし原因を知っていたら返答お願いします。自分の説明が悪かったですかね。使用するはずなんですよね。メッセージハンドラを実装するにはコントロールをサブクラス化する必要がありますね。chemoさん、ありがとうございます。再度説明していただいて理解しました。今回はISLeさんに教えていただいた方法でいこうと思います。今後のプログラミングの参考にさせていただきます^^一応、やりたいことはできたので解決にしときます。ここまでは完璧だったんですが、なぜか右上の×で終了しようとすると、なぜか終了してくれませんでした。今までは右上の×を押すだけで、恐らくDefWindowProcがウィンドウの終了処理をしてくれたんだと思うのですが、DefDlgProcではウィンドウの終了処理をしてくれないのでしょうか?右上の×を押すとメッセージ的には、WM_CLOSEは発生しているようなのですが、どうもDefDlgProcがちゃんと終了処理してくれないようです。その後にWM_COMMANDが発生して、WPARAMの下位ワードに2が入っていたため、あるボタンの処理が実行されてしまうというおかしな状況が発生しました(笑)なので、WM_CLOSEを直接処理するようにし、そこでDestroyWindowを実行して対処しています。これぐらいなら、問題ない範囲なのでまあよいのですが、もし原因を知っていたら返答お願いします。関数で終了する必要がありますよ。右上の×を押すとメッセージ的には、WM_CLOSEは発生しているようなのですが、どうもDefDlgProcがちゃんと終了処理してくれないようです。その後にWM_COMMANDが発生して、WPARAMの下位ワードに2が入っていたため、あるボタンの処理が実行されてしまうというおかしな状況が発生しました(笑)失念してました。WM_COMMANDのWPARAMの下位ワードが2というのはキャンセルボタンが押されたというイベントです。ダイアログは既定でOKのボタンIDが1、キャンセルのボタンIDが2となっていて、ウインドウを閉じようとしたのをキャンセルと見なしキャンセルボタンを押したのと同様の流れに持っていくための仕様です。ユーザー定義のボタンIDは1000番台くらいの大きい数値を使うのが良いと思います。WM_CLOSEを直接処理するようにし、そこでDestroyWindowを実行して対処しています。これぐらいなら、問題ない範囲なのでまあよいのですが、もし原因を知っていたら返答お願いします。知らなければもうこのままでいくので大丈夫です^^その対処方法で良いと思います。DefDlgProcはOKとキャンセルのボタンがあるつもりで動作するので↑に書いた『キャンセルボタンが押された』イベントに終了処理を書くというのでも良いかもしれません。関数で終了する必要がありますよ。chemoさんありがとうございます。WM_COMMANDのWPARAMの下位ワードが2というのはキャンセルボタンが押されたというイベントです。ダイアログは既定でOKのボタンIDが1、キャンセルのボタンIDが2となっていて、ウインドウを閉じようとしたのをキャンセルと見なしキャンセルボタンを押したのと同様の流れに持っていくための仕様です。ユーザー定義のボタンIDは1000番台くらいの大きい数値を使うのが良いと思います。その対処方法で良いと思います。DefDlgProcはOKとキャンセルのボタンがあるつもりで動作するので↑に書いた『キャンセルボタンが押された』イベントに終了処理を書くというのでも良いかもしれません。ISLeさん、ありがとうございます!そういうことだったんですね!原因もはっきりわかり、完璧に理解できました!ボタンIDは大きい数値を使うようにしておきます。これにて完全解決と致します。9年前CreateDialog系APIで作成したモードレスダイアログはDestroyWindowで破棄します。本件のようなCreateWindowで作成したモードレスダイアログっぽいウインドウも↑と同じです。DialogBox系APIで作成したモーダルダイアログはEndDialogで破棄します。私がどちらで破棄しようか迷っていたところまで見抜いて回答してくださるとは・・・!なんとなくDestroyWindowでいいかなと思ってはいましたが、これで確信に変わりました。ミクプラは自由にリンクできます。