・今日はお便り紹介。

・こんばんわ〜。さて、基本的に、各設定は全部同じにするのが一番だと思います。この設定（【プロジェクトの設定】ダイアログの【C/C++】−【コード生成】ページ）は、マシン語に変換するときの設定なんで、マシン語レベルでの違いが生まれちゃうんです。基本的には全部ＤＬＬ２の設定にして、「デバッグ」と「リリース」との両方を３つすべてに用意して丸ごと切り替えるようにする、っていう方法がいいと思います。
　
・あ、もしかして、こーやってそれぞれ変えてるってことには何か理由があるってことなのかな。それだと、単純に統一すればいいって問題でもないか。うーん、どうしよう。あと、「スレッドを作成」ってことはマルチスレッドってことだと思うんで、「プロセス」のランタイムは「マルチスレッド」にした方がいいと思います。ま、実際、わざわざシングルスレッドの設定にする必要はないんで。
　
・あとはまぁ、こういう設定とは関係ない部分の問題ってことも多いです。ＤＬＬまわりはデバッグが大変だから、どこに原因があるのか分かりにくいことが多くて。あ、ＤＬＬ２やプロセスＥｘｅがデバッグモードじゃないから、どこに問題があるのか分からないのかな。デバッグモードにしてその辺のチェックを念入りにした方が、色々模索するよりも近道だと思うです。
　
・でわまたっ！

・今日はお休み〜。

・眠いねぇ。っと、こっちは言わない約束ね（？）。今日はお便り紹介。

・初めまして〜。オプションはどうなんだろう、たいがいの人は gcc の本があるんでそれを読んで調べてるんじゃないかな。まぁ、基本的に gnu 系だからどっかにドキュメントあるんだろうけど、英語だと思うし、検索するといっぱい引っかかりすぎちゃうし、やっぱ本で調べるのが一番かなー。といいつつわては持ってない（爆）。それこそ -lstdc++ と -lm があればたいがい通っちゃうんで。
　
・でわまたっ！

・今日はＣマガを購入。でもあんま読んでない（汗）。Ｃマガよりも、もう休刊しちゃったインサイドウィンドウズの方がずっと読み返すこと多いんだよねー。 Ｃマガはプラットフォームが限定されてないから、話が概念的すぎて使いずらいっつーか。たぶんこーゆー雑誌って、個人購入よりも企業顧客の方が大きいから、幅広い方が売りやすいのかもなー。
　
・そういえば、夏休み中に FFT についての解説を書くとか言って、結局書かなかったね。今年の夏休みは色々あったからなー。構想はあるのに時間がない……。 STL & iostream 入門も一応Ｃｏｄｉａｎ化するつもりなんだけど、時間がどうか。ま、文章はすでにあるんだからその点では楽なんだけどね。１０月からも時間的には結構余裕あるし。さてどうするか。
　
・あ、あとプログラミング辞書の単語送信数、激減なんですけど……。
　
・でわまたっ！

・今日はお休み。

・今日もお休み〜。

・今日もお休み。だって最近、全然質問送られてこないんだもの＜質問がないとお休みってのが問題（汗）。

・ねだったら、質問がふたつ来ました（爆）。とゆーわけでまずひとつめ。

・初めまして〜。えーっと、まず(1)だけど、これは聞いたことないな〜。もしそうなら KNOWLEDGE BASE とかに載ってそうだけど見つからないし。(2)はちょっと分かんないです。じつはビットマップ関係ってよく知らないんで……。
　
・で、問題の件だけど、メモリデバイスコンテキストを作って BitBlt() するっていう方法はどうかな。デバイスコンテキストに直接貼り付けるときに重くなるんだとしたら、この方法で解決するんじゃないかな。コーディング方法とかはＣｏｄｉａｎのオーナードローメニューの作製（後編）とかを参考にしてください。
　
・もうひとつのお便り。

・送ってくれてありがとう！　で、 SetWindowsHookEx() が失敗する場合には、確か第４引数を指定したりするとうまくいく場合があったよーな。 MFC を使用してる場合には、第４引数に AfxGetApp()->m_nThreadID を渡したりするとうまくいくよーな気が。 NT 系のローカルフックはこうじゃなきゃダメ、みたいな記憶が……。とりあえず試してみてください。ってゆーか SetWindowsHookEx() って他に失敗する可能性低いからなー。あ、 GetLastError() で何か返ってくるかも……。
　
・うーん、なんかこっちでねだっといて、どっちも煮え切らない回答しちゃってますね（泣）。ごめんなさいです〜。
　
・でわまたっ！

・なんかむっちゃ初心者っぽい質問だけど、よく言われてる fscanf() の問題点ってなんなんでしょ。誰か具体的にばしっと教えて！　思い付くことはあるんだけどどれもいまいち説得力なくて。普段ランタイム使わないとこーゆーの辛いなー。いやね、ぷらとわで書くんで。それに会社入ったら iostream そんなに使えなさそうな気がするし。とゆーわけでよろしく〜！
　
・今日のお便り。

・解決したみたいで良かったです。ってゆーか、わても知ってたんだからＣｏｄｉａｎに書いとけば良かったんですね（汗）。今日の更新で書き加えておきますんで。これからも質問よろしくね〜。
　
・でわまたっ！

・あう、結局 fscanf() のこと誰も送ってくんなかった（泣）。だからお休み（爆）。
　
・でわまたっ！

・今日はお便りがふたつ。ではまずひとつめのお便り！

・お便りありがとう！　こちらとしては fscan() のことより休みになる方がイヤ〜ンなんで（爆）。これは「テクニカル ノート 11」に書いてあるのかな。はっきし言ってこのページに書いてある解説わかんない（爆）。 DLLTRACE 見れば分かると思ったらよく分かんないし。 MFC は複雑だし。むー。
　
・基本的に、メッセージポンプはスレッドに１個なんで、スレッドが１個だけなら DLL をいくらリンクしてもメッセージポンプは１個だけ。だから CWinApp::PreTranslateMessage() を呼び出しても DLL のメッセージポンプに投げられる、ってことはありえないんです。テクニカルノートに書いてあるのってちょっと違うことなのかもしんない。
　
・気になるのが ESP ってエラー。これって「不正な処理」とか書かれてるダイアログの「詳細」で出てくるのだよね。 MFC まわりのエラーの場合、普通 ASSERT() のエラーで出てくる Microsoft Visual C++ Debug Library ってダイアログが出ると思うんで、そうじゃないってことは MFC とは無関係の所でエラーが出てるのかもしれない。このエラーがどこで出てくるのかチェックできれば。
　
・ DLL 側ウィンドウの作成タイミングはいつでも大丈夫でしょう。エクスポートされた DLL 側の関数から普通に作成すれば大丈夫かな。それとも MFC 使ってるからそういうふうに自由にできないのかな。 Exe 側のウィンドウの登録ってのは、子ウィンドウに対する親ウィンドウとしての登録方法ってことかな。それは CWnd::Create() とかの引数に親ウィンドウを指定する部分があるから。
　
・ふと思ったんだけど、「ウィンドウの作成タイミング」ってことは、もしかして Exe 側のウィンドウができる前に DLL 側のウィンドウを作成しようとしてるのかな。それだとちょっとまずいかもしんない。親の CWinApp 派生クラスの m_pMainWnd が NULL のままだと動かないと思うから。そういう場合には、まずウィンドウを作っちゃって ShowWindow() で SW_HIDE とかして非表示ウィンドウ化しちゃった方が処理が楽かもしんない。むー、なんかやっぱ MFC って複雑っすね〜。
　
・ふたつめのお便り。

・お便りどうもですー！　これは IE なんかであったセキュリティの問題ですね。でも実はこれについて訊いてたわけじゃなかったり（汗）。「 fscanf() は fgets() と sscanf() で代用すべし」ってのが結構言われてるんだけどその根拠が曖昧だったんでそれが知りたかったとゆー。んでもスタックオーバーフローって実はよく知らなかったんで実はかなり役立ったり（爆）。
　
・やっぱ C++ 使ってるとこって少ないですよねー。わての知り合いとかの会社はどこも使ってないです。内定先はパッケージも作ってるんで、そっち回してくれるとうれしいんだけどね。でも組み込み系は家じゃ絶対できないことだから結構そっちも楽しみだったり（爆）。１０月２日の内定式ですこーし分かると思います。さてどうなるか。
　
・でわまたっ！

・毎日お便り送ってくれてありがとねん。では今日のお便り！

・えーっと、メッセージポンプっていうのは GetMessage() を使ってメッセージをメッセージキューから取り出して DispatchMessage() で各ウィンドウプロシージャにメッセージを送る部分のことです（Ｃｏｄｉａｎのウィンドウプロシージャの呼びだしと MSDN の「め」の「メッセージ ポンプ」の項目を見てください）。
　
・ MFC の場合、 CWinApp::Run() （正確には CWinThread::PumpMessage() ）にこのコードが書かれてます。『MFC と動的にリンクされるレギュラー DLL』を見ると、 Exe と DLL 含めてひとつの CWinApp::Run() が実行されるような仕組みになっているみたいです。これがつまり、スレッドひとつにメッセージポンプひとつ、をコードとして実現してるわけです（内部システム的にメッセージキューはスレッドにひとつだから）。
　
・「 DLL 側でモードレス ダイアログを……」ってくだりは、「メッセージポンプは Exe 側にしかないから以下のようにしないと問題が発生する」ってことみたいです。 CWinThread::PreTranslateMessage() の中身を見ると「モードレスダイアログのアクセラレーターテーブルの処理」を呼び出す部分があって、この関数を呼び出さないと DLL 側のモードレスダイアログのアクセラレーターテーブルが効かなくなるよ、ってことみたいです。 CWinThread::PreTranslateMessage() はメッセージポンプの前に呼び出す前処理用関数なんで、そういう機能が備わっているんでしょう。
　
・……ってゆーか、 MFC って複雑（汗）。わてとしては、拡張 DLL にしちゃった方が１００倍楽だと思うです（爆）。 CWinApp が DLL の中にあるってこと自体が複雑なのの原因のような気がするなー。拡張 DLL にすれば、 Exe と DLL の違いが全然ない形でプログラムできると思うです。拡張 DLL にして、普通に CDialog::Create() 呼び出して作るって形なら、かなり楽にできると思うです。支障なかったら拡張 DLL にしちゃいましょう。
　
・あ、でも、 DLL でダイアログ作る理由次第ではそうもいかないかなぁ……。
　
・でわまたっ！

・今日もお便り〜。

・おひさです〜。やっぱソースコードないと分かんないかも（爆）。あとエラー。この前の方も ESP がなんたらって言ってたけど、これって「不正な処理」ダイアログの「詳細」で出てくるのでいいのかな。実はどーゆーエラーが出てくるかでだいたい分かるんで。でも「だいたい」だけど（汗）。
　
・実際、「不正な処理」ダイアログの「詳細」欄は、単にレジスタの中身を表示してるだけなんで、まず役立たないと思うです。エラーを見つける場合には、デバッグモードで ASSERT() ばらまいて、ステップインしつつ変数の中身を見てくってとこかな。まーそれで見つかりゃ苦労しないんだけどさ（汗）。とゆーわけでそれはたぶんコード見た方が早いと思うですー。
　
・ついさっき（ただいま午後１１時）送られて来たのは明日ね〜。
　
・でわまたっ！

・今日もお便り紹介。

・ソースコードの方読んだけど、 SDK の時の「親ウィンドウの上に子ウィンドウ」と同じ形式を MFC でもやった方が楽だと思います。もともと MFC の SDI アプリは「 CFrameWnd 派生クラスの上に CView 派生クラス」って形になってるんで、普通に MFC の SDI アプリ作ってフレームウィンドウのタイトルとか取っ払ってビューと同じサイズにしてビューにビットマップ貼り付ける、って形がいいと思いますです。
　
・ SDI アプリの作り方は、 MFC App Wizard (exe) を選んで次のダイアログで SDI を選べばＯＫ。こうして CView 派生クラスの OnPaint() で件のコードを書けばうまくいくんじゃないかなー。ソースコードだとかなり無理してビュークラスを作ってるんでその辺でうまくいかないっぽいです。
　
・ってゆーかデスクトップに直接描画は危険すぎ（爆）。だからずれちゃってるんだと思うです。クリッピングとかもデスクトップウィンドウを基準にされるから、あんなふうに無茶苦茶な描画になっちゃってるんでしょう。ただ、こっちで CDisplay に描画する形に書き換えてテストしてみたんだけど、ウィンドウをはみ出させるとその部分が描画されなくなっちゃいました（汗）。なんでだろう。 MFC SDI アプリの形式にして OnPaint() で実行するようにしたらうまくいくことを祈ろう。
　
・ DLL の目的がモジュール化なら、迷わず拡張 DLL にしましょう。レギュラー DLL の場合、 MFC 関係がその DLL に詰め込まれちゃうんでおもいっきしファイルサイズが大きくなります。なんでいっぱい作るとかなり大変。拡張 DLL なら、ホントに外に出したいものだけを DLL に入れることができるんで使いやすいと思います。ただし、別に MFC42.dll とか必要になるけど（汗）。
　
・でわまたっ！

・今日はお便りをふたつ。まずはメールでサンプル送ってくれた方へ〜。
　

    char temp[] = "x ";
    char* Cmd_b = strcat( temp, Cmd_a);
	

　
・これがたぶん元凶でしょう。 strcat() は「第１引数の最後に第２引数を書き込む」とゆー仕様なんで、おもいっきし配列をはみ出ちゃいます。 char temp[_MAX_PATH] とかして strcpy( temp, "X " ) してあとはそのままって形がえーかな。でもこまめにオーバーフローのチェックはしましょー。それにしてもこの手のエラーが流行ってるよーな（汗）。
　
・普通の配列だと、オーバーフローのチェックが難しいんだよね。 VC のデバッグ版 new & delete だとその辺ばっちしチェックしてくれるからいいんだけど、そんなん使うくらいの人ならたいがいオーバーフローチェックは欠かさないですな（爆）。それに使うの面倒だし。 std::string 用アロケーターでこの機能付いてるの作るかなー。
　
・もひとつお便り。

・わては MFC から SDK 中心になったんだけど、それでもやっぱ気持ち悪い（爆）。 MFC はあかんね。えっと、結論から言うと大当たり、 AfxWndProc() の内部で振り分けてくれてるんで問題ないです。ウィンドウハンドルから CWnd::FromHandlePermanent() で CWnd ポインタを探し出してメッセージを送る仕組みになってます。その辺のことはＣｏｄｉａｎの「ＭＦＣユーザーのためのＡＰＩプログラミング講座」に書いてたりするんでそちらもご覧あれ。
　
・でわまたっ！