|
|
 |
2001/03/01 (Thu)
|
・今日はお便り紹介！
|
|
|
・うおホントだ！ これはかなりアヤシイなー、 MFC はモーダルダイアログを CreateDialogIndirect() で作るんだけど、この戻り値が NULL で、しかも GetLastError() で 0 が返ってきてる（汗）。なんで普通出るはずの "Warning: Dialog creation failed!" が出てないんだよね。
・この前のは VC の制限だったけど、これは API のだからねぇ。試してないんで想像だけど、たぶんコード上での追加はうまくいくと思うです。っていうのも、実はダイアログエディタ上のダイアログって、本物のダイアログなんです。コントロールを追加するたびに実際にそのダイアログに追加されてるとゆー。 ・ Spy++ で照準合わせてみるとダイアログ全体やコントロールに照準合うんで分かると思うです。だからダイアログを表示してから追加ならたぶんうまくいくと思うです。たぶんそれしかないだろうなー、 API の問題だからねぇ。それかもしかしたら、 Win9x 系だけの問題だったりするのかも。それでもどうしようもないか。 ・でわまたっ！ |
|
2001/03/02 (Fri)
|
・今日もお便り紹介〜。
|
|
|
・実はドラッグアンドドロップって詳しくなかったり（汗）。なんでちょっと調べてみたんだけど、どうも見つかるのは「ドロップを受け付ける方法」ばっかし。でやっとこさサンプルコードの情報を見つけました。試してないんでこれでうまくいくかどうかは不明。っつーか COM インターフェイスを自前で作る必要があるみたいです（汗）。 結構難しそう……。
・もひとつお便り。 |
|
|
・おおっ、とうとう完成しましたね！ 試してみたけど、ホントにエディタらしくなっててすごいです。ちゃんとカーソルが動くんだもんなー。で、その不具合はこちらでは再現できなかったです。大きなファイルを見繕って、関連づけしてダブルクリックして、カーソルキーの下を押しっぱにして、ってしてみたけど落ちなかったです。
・デバッグビルドとリリースビルドの違いは「プロジェクトの設定」の違いだけなんで、一部をリリースビルドっぽくしてあとはデバッグビルドで、っていうこともできたりします。詳しくは尺八郎さんのページとか「金菜さんの憂鬱」過去ログの１９９７年７月２０日前後を見てくださいです。でもやっぱ、リリースビルドだけの謎のエラーって絶対あると思う（爆）。ホントに謎なんだよなぁ……。 ・でわまたっ！ |
|
2001/03/03 (Sat)
|
・今日はぷらとわやかなゆ〜を書いてました。ぷらとわは１０１号から Ver 6 になります。でもいつまで続くのやら（汗）。かなゆ〜、１００号で最終回にします（汗）。結構書くのに疲れちゃったっていうのあるかなぁ。前は気軽に書いてたんだけど、最近は BCC や gcc でのコンパイルチェックをしてからっていうのがあって、負担大きくて。書くネタもないし。
・あと……ここ、かぶゆ〜もたぶん３月一杯……。かぶヘッダーでちょこっと書いたけど、基本は「とりあえず休止させて、大丈夫そうもしくは必要なら再開」ってスタンスで行く事になると思います。どうも３月４月に対する不安が非常に強くて……。もしかしたら３月なかばにも休止するかも（汗）。あ、あと辞書も３月一杯だかんねー。 ・でわまたっ！ |
|
2001/03/04 - 06 (Sun - Tue)
|
作者沖縄旅行のため休載
|
|
2001/03/07 (Wed)
|
・おひさっ！ では休み中に送られてきたお便り！
|
|
|
・ COM を直に作っていくのはかなり大変だと思うです。わても IDL って書いたことないし文法も知らないです（汗）。 VC を使ってるなら「プロジェクトの新規作成」で ATL COM AppWizard か MFC ActiveX ControlWizard で作れば必要なファイルは全部用意されると思うんで、そこから解析していった方がいいかも。
・ COM を直に作っていく場合には「 Inside COM 」って本がお奨め。 COM の実装方法が書かれてて、最初の方は IDL とか使わないタイプの COM について解説してるんでそっから作っていくのがいいかもしんない。この辺の COM の仕組みは、なんかのプラグインにも使われてるらしいんで勉強しておいて損はないと思うし。まーでも、 .Net がスタートしつつある今はもう COM の時代じゃないのかもしんないけど……。 ・もひとつお便り。 |
|
|
・実際にその検索試してみたんだけど、検索が終了しませんでした（汗）。「ロジテック」で検索したんだけど……（うちはセレロン３６６メモリ１９２）。どの辺が原因か分かんないんだけど、検索に DOM を使ってるんなら SAX にした方がいいかも。実際「 DOM の特徴」みたいな文書に「 DOM はすべてを読み込んでから処理するから遅い」って書いてあるんで。 SAX は上から逐次処理するから少し早いかも。
・あとは、 XML ファイルをひとつにしないで、まずメーカー別とかに分けて検索時に選ぶようにしてもらうとかかな。あと、出力結果を PC 上でできるだけいろんな種類生成してそれを表示させるようにするとか。でもやっぱ、根治療法は CGI で処理することかなぁ。できるだけ安くて CGI 使えるとこを探して、検索機能だけそこに置くようにするとかした方がいいかもしんない。 ・かなゆ〜はとりあえず休止！ そのあとは、仕事環境次第。まず基本的に仕事がきつかったら書く暇ないし、仕事が楽でも、プログラミング＝仕事だからそれが（いろんな意味で）書けるかどうかわかんないし。あーあと、かなゆ〜の最終回は今月の１６日か２１日になる予定。今度のかぶヘッダー送信予約までには決まるはず。訊きたいことがあったら今のうちに〜。 ・でわまたっ！ |
|
2001/03/08 (Thu)
|
・……決めた！ この「鏑矢の憂鬱」は、今月の１６日（金）の分で休止状態に入ることにします。むむ、っつーことは約１週間後！？ 自分で決めといてなんだが、結構急だなぁ（汗）。まー、早めに決めちゃった方が後々楽っていうのもあるし、その方が再開も早いかも？＜ホントかなぁ（汗）。
・あと、プログラミング辞書は２１日（水）午後１１時に単語受付を休止します。かぶゆ〜はともかく、辞書は最近単語が少なかったから、あんまり影響ないかも。さらに、１９日（月）には KTL 、 KCL9542 、 まどかぶ、けしかぶのマニュアルページを削除する予定。ダウンロードは引き続きできるようにします。 ・基本的にはこの予定で行きます。少なくとも、来週月曜のかぶヘッダーにはこの予定が載るはず。たーだ、金曜や水曜とかの中途半端な日時になってるのは就職関係や卒業式の関係なんで、他に予定が入ったら日時が変わるかもしんない（汗）。ま、逆に言えばいちんちやふつか延ばすことなんか問題ないんで、そんなに神経質になることでもないかも。 ・でわまたっ！ |
|
2001/03/09 (Fri)
|
・お便り受付は１６日（金）午後９時まで！ どうしても解決できない、でも誰にも訊けないプログラミングの難問があったら今のうちに！ 答えられるかどうかは別にして（爆）。では今日のお便り。
|
|
|
・確か CString は大きなサイズの文字列を操作するの苦手じゃなかったかな。重くなるのはその辺が原因かも。とりあえず手っ取り早いのは std::string を使うことかも。これは普通にメモリを確保するはずだから、大きなサイズでも大丈夫……だと思う（汗）。ファイルを開くときにそのサイズを調べて、 std::string::size() で確保して渡すとかすれば大丈夫なはず。
・後はやっぱ、書かれてるよーに、 CString を１行ずつに割り当ててとか new で大きく確保してとかかな。あと思い付くのとしては、「余分に確保しない」とか。ギリギリ確保して、それ以降の入力は「ログ」として取って別に保存してくとか。これだとアンドゥしやすそう。この辺は、実際に各エディタの企業秘密とかなのかも。逆にうまいシステム考えれば対抗手段になるかも！ ・えーっと、休止以降は「チョー普通な日記」で質問して大丈夫（爆）。本格的な回答とかは（時間的に）できないかもしんないけど、それこそ気軽に訊かれるんなら全然問題なし。あっちもツッコミ少ないし（爆）。メールでもいいしね。ホームページが色々変わるってだけで、わて自身が変わるわけじゃないんで……たぶん（爆）。会社入って変わったら嫌だなぁ。 ・でわまたっ！ |
|
2001/03/10 (Sat)
|
・今日はお休み（爆）。お便り受付は１６日（金）午後９時までなんだから今のうちに！
|
|
2001/03/11 (Sun)
|
・お便り受付は１６日（金）午後９時まで〜。というわけで今日のお便り！
|
|
|
・おおっ、解決しましたか。 CString の連想配列みたいな感じかな？ 確かにこれなら操作が面倒じゃないし、無駄も少なそう。お仕事はなー、内容がどうなるか……。ま、なんにせよがんばりますです。とりあえず３０歳まではいるようにしよう（爆）。
・でわまたっ！ |
|
2001/03/12 (Mon)
|
・お便り受付は１６日（金）午後９時まで、ってことはあと４日？ いや見てる人はもっと後だろうから……ダッシュ！ というわけで今日のお便りですよ（なんだこのテンションは）。
|
|
|
・うお、こんなランタイムがあったなんて知らなかった！（爆） で、 void * っていうのは「汎用ポインタ」、つまり「なんにでもなるポインタ」って意味で使います。この bsearch() は、どんな要素の配列でも検索できるランタイムとして設計されてます。だから、 int のポインタも double のポインタも、とにかくどんなポインタでも受け付けますよ、って意味になってます。実際に void * にはキャストなしでどんなポインタも暗黙的変換ができるしね。じゃ、実際に使用例を見てみましょー。
// 比較用関数。
int compare_int( const void *p_piLh, const void *p_piRh )
{
return *(int *)p_piLh - *(int *)p_piRh;
}
// では使ってみましょう。
void Test()
{
const int iSource[] = { 100, 200, 300 };
TRACE( "%X\n", iSource );
const int iKey = 200;
int *piRes
= (int *)bsearch
( (const void *)&iKey // 見つけたい値。
, (const void *)iSource // サーチ対象。
, 3 // 要素数。
, sizeof( int ) // 要素のサイズ。
, compare_int ); // 比較関数。
if( piRes != NULL )
{
TRACE( "%X, %d\n", piRes, *piRes );
}
else
{
TRACE( "ない！\n" );
}
}
// 結果
// 64F444
// 64F448, 200
・まず比較用関数を用意します。これは上記の compare_int() のような引数と戻り値を持ってる必要があります。実装については後で。 ・ bsearch() はどんな要素の配列でも検索できます。なので、まずその検索対象にする配列 iSource を用意しました。これは「ソート済み」じゃなきゃダメ。わてが参考にした MSDN のリファレンスでは、 qsort() でソートしてますです。ここではあらかじめソートした状態にしておきます。 ・では実際に bsearch() を呼びます。第１引数には「見つけたい値」へのポインタを渡します。ポインタって事が、 compare_int() の実装に関わってきます。第２引数は検索対象。これもポインタで。第３引数は、第２引数の要素数。ここでは３つ。第４引数は要素のサイズ。ここで要素のサイズを教えるから、各要素のアドレスを計算できて、「どんな要素の配列でも検索できる」ようになるんです。 ・第５引数はさっきの比較用関数。で、この実装についてだけど、第１引数には「 bsearch() の第１引数そのもの」が渡されます。第２引数には「 bsearch() の第２引数の各要素へのポインタ」が渡されます。つまり、 compare_int() が呼び出されるたびに、 &iSource[0] か &iSource[1] か &iSource[2] かが渡されるってこと。 ・この比較用関数が bsearch() から呼び出されて、その戻り値を元に検索します。戻り値は、第１引数の方が小さければマイナス、大きければプラス、同じならゼロを返すように実装する必要があります。ここではただ引き算してるだけです。で、この比較用関数がゼロを返した要素へのポインタを bsearch() が戻り値として返すんで、それでどこにあるのかが分かります。 ・この void * と比較用関数の仕組みのおかげで、どんな要素の配列でも検索できるようになってるんです。構造体でもクラスでも文字列ポインタでも。まー、今はテンプレートっちゅー便利なもんがあるからこんなポインタ操作なんてしなくてもいいんだけど、プレディケート作って STL のコンテナとアルゴリズム用意してって方が面倒って人の方が多いんだろうなぁ……。 ・もひとつお便り！ |
|
|
・うわホントだ、入力するたびに例外が出ますね。こりゃあかんわ。でも背景色が変えられるのはリッチエディット２．０かららしい……。なんで RichEdit20A を Google にかけたら CRichEdViewEx なるものを見つけました。サンプルをビルドしたら問題なく使えたんで、これをうまく移植すれば大丈夫だと思うです。
・で……実際に、今例外が出まくった例のでビュークラスを CRichEdViewEx から継承するようにしたんだけど、必ず閉じるときに例外が出るなー。上の例だと出ないんで、もしかしたら CRichEdViewEx から継承しちゃいけないのかも。とりあえず上のでできそうなんで試してみてくださいです。 ・でわまたっ！ |
|
2001/03/13 (Tue)
|
・お便り受付は１６日（金）午後９時までですよー。では今日のお便り。
|
|
|
・がんばります〜。なんせバイトのプログラミングとかもしたことないんで結構不安だったり、っていうか仕事がプログラミングかどうかも不明……。 C4786 をうち消す #pragma は、 MFC を使っているんだったら stdafx.h のいっちゃん最初くらいに書けばたぶんうまくいくと思うです。
・こっからはかなりややこしい話。 std::pair が定義されてる utility をインクルードしててもコンパイルエラーが出ないのは、テンプレートは「使わなければ無視される」から。 std::pair を使ってないときはコンパイルエラーが出なかったんだけど、使うと実体化（インスタンス化）されてコンパイルエラーになるんです。 ・ utility ヘッダーファイルは、 algorithm や iterator 、 vector とかのヘッダーファイルからもインクルードされてるから、 #include <algorithm> の後で #pragma してると #pragma が間に合わない、ってことが原因なのかなーと。各 .cpp ファイルからのインクルードの兼ね合いとかも原因の可能性有り。ま、とにかくできるだけ早く #pragma がコンパイラに認識されるようにすれば問題ないと思うです。だから stdafx.h の最初に書いちゃいましょう。 ・もひとつお便り。 |
|
|
・ホントだ、 DeleteObject() って同じハンドルを何度も渡しても非ゼロが返ってくるんですね。基本的には Create と Delete は malloc() と free() の関係なんで、メモリを解放してるはず。実際、 DeleteObject() した hRgn をウィンドウに SetWindowRgn() してもゼロが返ってくるし。だから削除はできるはず。
・ただ、この例だとまずいと思うです。 SetWindowRgn() するってことは、そのウィンドウが hRgn に常にアクセスするってこと。ハンドル＝ポインタだからね。だから DeleteObject() しちゃうと、ウィンドウが解放されたメモリ領域にアクセスすることになるからそれが原因かも。 ・ _msk.GetAniRgn(); がよく分かんなかったんで完全なテストができなかったんだけど、こっちではアクセス違反は発生しなかったです。このときテストできなかった _msk.GetAniRgn(); や CombineRgn() が原因でアクセス違反が起きたのかも。ハンドルの管理はポインタの管理と同じ、つまり結構大変ってことなんで気を付けないと大変かも。 ・でわまたっ！ |
|
2001/03/14 (Wed)
|
・今日は、本屋で立ち読みしてきた方法で XML ドキュメントを新たに作成してみる。ずっと「 <?xml ?> ヘッダはどう書き込めばいいんだろう」とか思ってたんだけど、なんのことはない、 DOMDocument.loadXML() で文字列そのものを読み込むことができるんですね。これでなんとか。
・ただ、今は VBScript でやってるんで結構限界が（汗）。 "" の中に " を書き込むにはどうすればいいんだろうとかで悩んだり（単に "" ってすればいいらしい……）、謎のランタイムエラーに悩まされたり（これはまだ解決してないし……）、やっぱ VC でやった方がいいかもなー。 ・今日のお便り。 |
|
|
・はう〜「師匠」だなんて〜（照）。この鏑矢の憂鬱休止まであと２日。皆さんにとってはたぶん明日、ってことでしょう。まー、この前書いたように日記の方で質問してもいいし、知ってる人は知ってると思うけどメールで質問したってくれてもちゃんと答えるし、そんなに気にしなくていいと思うですよ。まー前みたいな気軽さはないかもしんないけど、ある意味日記はここより気軽だから（爆）。
・でわまたっ！ |
|
2001/03/15 (Thu)
|
・投稿は１６日午後９時まで！！ っつーことはもはや残り２４時間を切ったのでは！？ これが質問のラストチャンス！ たぶん。では今日のお便り！
|
|
|
・えーっと、一番簡単なのは operator<<() を m.h の中（ class m のあとね）に置くこと。この例、 operator<<() の実装を空にしとけば別に friend 指定しなくても大丈夫なはず（ friend 指定は m の private メンバにアクセスするときだけ必要だから）。なのに、リンクエラーが出るでしょ。
・この辺は「テンプレートのインスタンス化」って部分。コンパイラが m.cc をコンパイルするとき、 operator<<() を「テンプレートだし、使われてないからコンパイルしなくていいや」って判断します。 << は main.cc の方で使われてるから、 m.cc をコンパイルする時点では operator<<() のテンプレート引数を指定できないんで。機械語コードにコンパイルされてないから、リンカが「その関数を呼び出すリファレンス」を解決できないんでそういうエラーが出るとゆー。 ・あ、もしかしたら、メンバ関数として operator<<() 作ってたときはうまくいってたのかな。確かに template class m<int>; でなんかインスタンス化されてるような気もする……。でも、一応テンプレートはヘッダーファイルに全部書いちゃう方がいいと思うです。その方がテンプレートっぽいし（爆）。 ・もひとつお便り。 |
|
|
・はじめまして〜、そしてありがとうです！！ いやー、 createProcessingInstruction() なんてメソッドがあったんですね。これで最初の <?xml ?> 部分を普通に加えることができるんですね。確かに loadXML() 使うのは力業っぽい……。
・それに、ノード追加する前にまず createElement() 呼んで documentElement に格納しなきゃいけないんですね、これが分かるのにかなり時間かかった……。そのあと createTextNode() の戻り値を documentElement.appendChild() したらエレメントに要素加えることができたです。これで一歩前進です〜、ありがとう！ っつーかもっと情報集めないとなわて……。 ・もひとつお便り。 |
|
|
・ホントだ、 EN_SELCHANGE メッセージが２回連続で送られてきますね。各メンバもまったく同じだし、なんか謎だ……。うーん、一番いいのはフック掛けるかサブクラス化して、キー入力を全部ログってく、ってのかなぁ。全部でなくても BS とかだけ取って、そのあと送られてきた EN_SELCHANGE は特別な処理する、とか。なんか根本的な解決法って感じじゃないな……。
・っつーか、これ以上リッチエディット使ってくと、問題が雪だるま式に増えてきそうな気が……。 ・でわまたっ！ |
|
2001/03/16 (Fri)
|
・今日はかぶゆ〜最終回！ ま、一応休止扱いだけどね。かぶゆ〜の前身だったかなゆ〜は１９９７年９月からスタートしたんだけど、途中何度も休止してたし、かなゆ〜からかぶゆ〜になった間も休止状態だったし。何ヶ月かしたら、またかぶゆ〜始めたくなったりするのかもなー。ま、とりあえずこれまでのご愛顧、ありがとさん！ これからはチョー普通な日記の方でね。
・では今日のお便り！ |
|
|
・んー、なんか設定がうまくいってないのかな。まとめると、まず StdAfx.h で「プリコンパイルしたいヘッダーファイル」をインクルードして、 StdAfx.cpp 他各ソースファイルから StdAfx.h をインクルード。で、「プロジェクトの設定」の左ツリーで各ソースファイルに対しての「 C / C++ 」−「プリコンパイル済みヘッダー」の設定で、 StdAfx.cpp だけ「プリコンパイル済みヘッダーファイルの作成」（ /Yc"stdafx.h" ）、それ以外のソースファイルは「プリコンパイル済みヘッダーファイルを使用」（ /Yu"stdafx.h" ただしこれは各ファイルの時は出ない）ってすればうまくいく、はず。
・基本的には、 StdAfx.h で「不変なヘッダーファイル」をインクルードして、 StdAfx.cpp が「作成」、他のソースファイルは「使用」になってりゃ大丈夫なはず。こんときに、 StdAfx.h でインクルードすべきファイルを各ソースファイルからインクルードしてたりするとうまくいかなかったりしたような気が……。「コピーした」とかってあるから、それがなにか影響してるのかも。 ・ mainCRTStartup ってどっかで見たような……確か初期処理をしないからファイルサイズが小さくなるとか起動が早くなるとか？ 違ったかも（汗）。 MSDN 見ると「そっから main() 呼ぶ」書いてあるから順序的には重くなりそうだし、記憶違いかも。 Ruby ……わてもクロ現出たい（爆）。でも出るんならサービスプロバイダなサイトの方がいいだろうなぁ。あー引っ越したらフレッツ ADSL 入ろっと。あれ、 IP もらえたんだったっけかな？ ・ま、いーや。そんじゃ、でわまたっ！ |