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