著作一覧 |
ruby-talk:298615読んだが、意味不明だ。
というのは、ビジーダイアログを表示するのは、MFCだからだ(olemsgf.cppの152行目以降)。独自にMFCのDLLを作って、それをdl経由で呼ぶとかしているのだろうか?
それより気になるのは、78行目でCoRegisterMessageFilterを呼び出すのだが、previousパラメータにNULLを与えている。ということは、独自にインストールしたMessageFilter以外はきれいに無視するということだ。
Win32APIを使ったプログラムを作っていれば、当然のようにWin32APIを参照する。
そこで、「検索する文字列」にたとえばMsgWaitForMultipleObjectsとか入力すると、右上のコンテンツペインが開いて表示される。
ほぼ100%、それはWindows CEのドキュメントだ。
しょうがないので、キーワード検索の結果から、プラットフォームSDKのほうを選択し直す。
これが、夢のように高速なツールであれば、少しはましかも知れないが、のろまで亀なMSDNのdexplorerだ。dexplorerのdは、ダメのdだろう。explorerに輪をかけてどうしろと。
というわけで、常に、そう常に、検索して、待たされて、表示されたものを無視して、結果を選択して、待たされて、再表示させるというバカなことを我慢することになる。すごいストレスだ。
問題は、Windows CEのドキュメントは必要だということだ。
つまり、フィルタリングは役に立たない。プラットフォームSDKを陽に設定したくはない。なぜならば、同時にATLだったり.NET Frameworkだったりの関連する項目も検索したいからだ。しかも、上で書いたようにCEのドキュメントは必ずしも不要ではない。というのは、場合によってはドキュメントが後で書かれただけに、SDKより詳細が書かれていたり説明がうまかったりすることが稀にあるからだ。つまり、場合によっては参照したい。
つまり、必要な機能は、キーワードの検索の結果表示の優先順位だ。
ということくらい、あのMSのことだから気づいて直すだろうと思っていたが、気づけば5年以上たってるじゃん。VS .NETのころからだよ。
本当に、視野の狭い検索しかしてないってことか?
いや、MSの連中にとっては、オンラインMSDN検索は、イントラネットだから超高速なのかも知れない(きっとそうなんだろう。だから、何かとオンライン検索をさせたがるのに違いない)。それなら、ローカルのMSDNを参照したりはしないだろう。だが、残念なことに、インターネットを経由すると、ローカルより、もっとのろいのだ(っていうか、企業とかだと相当困るだろうと思う)。しかも安定した速度でレスポンスが返るわけでもない。インターネット検索より、ローカルMSDN検索のほうが、いくらdexplorerがくずでもまだ高速なんだよ。気づけよ。
ジェズイットを見習え |