問題タブ [message-pump]

pythoncom.PumpMessages()関数またはpythoncomモジュールについて説明されたドキュメントがあまりないことに驚いています。

では、何をし、どのようpythoncom.PumpMessages()にpythoncom.PumpWaitingMessages()行うのでしょうか? 私が実際に知っているのは、入力デバイスからイベントをキャッチするために使用されることだけです。

私はサードパーティ製のオープンソース コントロールを持っています (どれが重要かは重要ではありませんが、CefSharp の Chromium Web ブラウザー [v 43])。

当初、コントロール内をクリックしたときにフォーム メニューが開いている場合、メニューが閉じられないという問題がありました (コントロールがクリック イベントを飲み込んでいるかのように)。

これを回避するために、サンプル アプリケーションは、フォームとコントロールの間でWM_MOUSEACTIVATEメッセージをインターセプトし、 WM_NCLBUTTONDOWNを含むフォーム (私の場合はパネル バー) の要素に戻すことで対応することを提案しました。これでその問題は解決しました。

しかし、それは別のものを作成しました。これで、コントロール (タッチ スクリーン) の内側を 3 回以上タッチすると、そのコントロールの外側の要素にタッチできなくなります。[外部要素] をマウスでクリックして、タッチ イベントに再度応答するために必要なフォーカス レベルを復元する必要があります。

WM_SETCURSORメッセージ (コントロールへの)もインターセプトし、ポンプを 5 ミリ秒ブロック (Thread.Sleep()) すると、問題が魔法のように解消されることを発見しました。

何が起こっているのか知りたいです。私は、それがスレッド/コンテキストの問題であるか、またはWM_SETCURSORメッセージを遅らせることで、フォーム内の隣接するメッセージを最初に処理できるようにするという理論の中間にいます (同じスレッドを共有するため、これは真実ではありません)。

そこで、(5 ミリ秒のスリープなしで) テストを実行し、コントロールとフォームが受信したすべてのメッセージをリアルタイムで記録しました。テスト中、パネル バー (ブラウザー コントロールの上) をマウスでクリックしてから、コントロール内のさまざまな領域に (長短を問わず) タッチしてから、もう一度バーにタッチしました (これは無視されました)。

メッセージは次のとおりです。

これらによると、3 回目と 4 回目のタッチでフォーカスが外れました。クロム コントロールが 586 の後に最後の一連のメッセージの受信を停止したことがわかります。問題の原因となったフォームへのWM_PARENTNOTIFYバックアップの欠如が原因ではないかと推測しています。

282、581、582、583、586、および 587 メッセージに関する情報が見つかりません。586 メッセージに反応して、手動でWM_PARENTNOTIFYをフォームに投稿できますか? 2つ続けて受けたらどんな効果があるのか​​わからない？

WM_SETCURSORの 5 ミリ秒のスリープがこれらのメッセージを流し続ける理由を知っている人はいますか?

または、修正に関するより良いアイデアはありますか？

これに対する答えがどこにも見つからないようです。どう表現すればよいか分からない。

フォーム上のコントロール宛てのメッセージは、互いに並行して処理されますか?

私は常に、スレッド アパートメントごとに 1 つのメッセージ ポンプがあり、1 つのポンプがそのスレッドに接続された GUI 全体にフィードするという印象を受けていました。では、1 つのコントロールで wndproc にフックしてスレッド (Thread.Sleep()) をフリーズすると、フォーム全体がフリーズするのでしょうか?

もしそうなら、この質問は、特定のメッセージが子コントロールに到着したときにスリープすることによって、隣接するコントロールが次のメッセージを処理したことを証明しているようです。どのように？

[バックグラウンドワーカースレッドで]ファイルを1行ずつ読み取り、[BeginInvokeを使用して]データグリッドビューにデータを入力するWindowsフォームアプリケーションを開発しています。これが行われている間、UI は応答しなくなります (キャンセル/終了またはウィンドウをドラッグできません) が、datagridview が更新されているのを見ることができます。私が知っているのは、これは、メッセージがユーザー入力メッセージよりも優先度の高いメッセージ キューに送られているという事実によるものです。

ユーザー入力に対する UI の応答性を維持する方法はありますか?

プログラム (以下のコード) を実行し、USB ケーブル経由でハード ドライブを挿入すると、device-change event typeWindowProcedureのメッセージに対して が呼び出されます。WM_DEVICECHANGEDBT_DEVICEARRIVAL

ただしGetMessage返さない。のドキュメントはGetMessage言うGetMessage

呼び出しスレッドのメッセージ キューからメッセージを取得します。

したがって、スレッドのメッセージ キューにメッセージがないように聞こえます。

呼び出しスレッドのメッセージ キューにメッセージがないのはなぜですか?

呼び出しスレッドのメッセージ キューにメッセージがない場合、デバイス変更イベント タイプWindowProcedureのメッセージに対して関数がどのように/なぜ呼び出されるのですか?WM_DEVICECHANGEDBT_DEVICEARRIVAL

注: 関連する投稿やページをいくつか読みました。 このスタックオーバーフローの投稿は関連しているようです。その場合、どのメッセージが実際にメッセージ キューに配置されるかを知るにはどうすればよいですか?

プロジェクト用に独立したウィンドウ ラッパー クラスを作成しようとしています。ほとんどの場合動作していますが、メイン メッセージ ポンプで WM_QUIT を取得する方法がわかりません。Windows を学習するために、他のライブラリを使用したくありません。

これは何が起こっているかの簡単な例です。

PeekMessage のドキュメントはこちら: https://msdn.microsoft.com/en-us/library/windows/desktop/ms644943(v=vs.85).aspx

-1 HWND フィルターを使用する例を見つけることができませんでしたが、MSDN によると、HWND が NULL の場合にスレッド メッセージを受信するとのことです (これが WM_QUIT に当てはまることを確認しました)。 WM_QUIT で行います。

この問題は、ウィンドウを作成した場合にのみ発生します。

私が間違っていることはありますか、それともより良い方法がありますか?