2

停止ボタンと再読み込みボタンの横にあるInternetExplorer8のURLバーにカスタムウィジェットを挿入しようとしています。これは私自身の個人的な生産性向上剤にすぎません。

IEフレームのこの部分の「ウィンドウモデル」は、IE8のURLバーを構成するウィンドウ（編集ボックス、コンボコントロール、停止ボタンと再読み込みボタン）を所有する「アドレスバールート」ウィンドウです。

別のプロセスから、IEのアドレスバーのルートウィンドウを親とする新しいWS_CHILDウィンドウ（カスタムクラス名を使用）を作成し、編集ボックスの兄弟にして停止/再読み込みします。HWND_TOPのhwndInsertAfterを使用してSetWindowPosを呼び出し、URLバーの「上」（つまり「中」）に表示されることを確認します。これはうまく機能し、ウィンドウが最初にIEのURLバー内にペイントされているのがわかります。

ただし、IEウィンドウをアクティブにすると、urlbar編集コントロールがウィンドウの前に戻ります。ウィンドウがURLバーの後ろにペイントされているのがまだ表示されているため、また、タイマーでデバッグコンソールに-> GetTopWindow（）を出力すると、URLバー編集コントロールのHWNDになるため、これが発生していることがわかります。

メッセージループを更新して、WM_PAINTでHWND_TOPを使用してSetWindowPosを呼び出すと、状況が改善されます。IEウィンドウをアクティブにして移動すると、コントロールがURLバーの編集コントロールの上に適切に配置されたままになります。ただし、IEのURLバーの編集コントロールのテキストを更新するIEタブを切り替えるとすぐに、コントロールは編集コントロールの後ろに戻ります。（注：これは、ウィンドウを最大化または復元したときにも発生します。）

だから私の質問は：

1）IEでタブをクリックするたびに、IEが意図的にURLバー編集コントロールをz-orderの上に戻している可能性がありますか、それともWindowsのペイントとz-orderingがどのように機能するかについての私の理解にギャップがありますか？私の理解では、子ウィンドウのz順序（エンドユーザーが操作できない）を指定すると、プログラムで変更されるまでその順序を維持する必要があります。したがって、IEはタブの選択時に編集コントロールを再描画しますが、ウィンドウを再描画したり操作したりしていなくても、ウィンドウはしっかりと上に表示されたままになります。

2）ウィンドウのz順序が明らかに変化していることを考えると、WM_WINDOWPOSCHANGING / WM_WINDOWPOSCHANGEDを​​受け取るべきではありませんか？もしそうなら、私は少なくともそのイベントに応答し、編集コントロールの上に自分自身を保つことができました。ただし、タブをクリックするとurlbar Editコントロールの背後にウィンドウのペイントが表示され、デバッグウィンドウの出力で、タブをクリックするとアドレスバーのルートのGetTopWindow（）がEditコントロールのHWNDになることが確認されます。 、およびWM_WINDOWPOSCHANGING / WM_WINDOWPOSCHANGEDがHWND_TOPのhwndInsertAfterを使用してEditコントロールに送信されているのを確認しても、タブをクリックすると、自分のウィンドウにメッセージが表示されなくなり、z順序を一定に保つことができます。これは私には間違っているように思われ、それに対処すると、IEで実行する必要があります。

ご協力ありがとうございました！

4

1 に答える 1

2

  1. タブを変更すると、IEがコントロールのZオーダーを調整している可能性が非常に高くなります。IE9では、URLバーとタブに共通の親があります。新しいタブを選択すると、URLバーがアクティブになります（アクティブにすると、通常、ウィンドウがローカルのZオーダーの一番上に表示されます）。

  2. いいえ。SetWindowPos関数がウィンドウに作用すると、WM_WINDOWPOSCHANGEDが取得されます。一部の兄弟のzオーダーが変更されている場合、メッセージは表示されません。あなたのウィンドウでSetWindowPosを呼び出した人は誰もいません。これは、いくつかの子ウィンドウのzオーダーを調整するテストプログラムを作成することで確認できます。

これは、任意の数の兄弟ウィンドウが存在する可能性があり、それらすべてに通知するための無制限のオーバーヘッドになる可能性があるため、理にかなっています。また、一部の兄弟がzオーダーをさらにシャッフルすることで反応する可能性があることを考えると、これらのメッセージをすべての兄弟に配信するための一貫した一連のルールを考え出すことはほぼ不可能です。最初の通知をまだ受け取っていない兄弟には、2つの保留中の通知がありますか？すぐに投稿または発送されますか？キューが大きくなり、オーバーフローするまで大きくなるとどうなりますか？

これは、最大で2つのウィンドウに影響するという点で、WM_KILLFOCUS/WM_SETFOCUS通知とは異なります。これにより、通知の数に合理的な制限が課せられます。負けたコントロールがフォーカスを取り戻そうとするために暴走する無限ループがあったとしても、配信されたWM_KILLFOCUSごとにSetFocus呼び出しが1つしかないため、キューはオーバーフローしません。

また、ウィンドウがフォーカスの喪失に反応する必要があるかもしれないことは合理的です。ウィンドウCがBがAの上にあることを知る必要がある可能性ははるかに低いので、なぜ無数の不要なメッセージを送信するようにシステムを設計するのでしょうか。

制御していないアプリや、やりたいことを実行するための明確に定義されたAPIがないアプリのUIをハッキングすることは、困難なことから不可能なことまであり、常に脆弱です。ツールバーとブラウザーのカスタマイズを提供するグループは、予想よりも多くの人を雇用し、1日の大半をSpy++の調査と実験に費やしています。それは本質的にハッキングです。

于 2011-06-14T20:33:21.547 に答える