問題タブ [getmessage]

特定のマクロを置き換えないようにプリプロセッサに指示するにはどうすればよいですか?

具体的な問題は次のとおりです。 Windows ヘッダー ファイルは GetMessage マクロを定義します。

API を含む C++ ヘッダー ファイルには、GetMessage メソッドがあります。メソッドの名前を変更したくありません。しかし、Windows で API を使用する場合、windows.h をインクルードすると、GetMessage メソッド呼び出しが GetMessageA に置き換えられます。

私の Delphi アプリケーションには、メッセージ待機ループを持つスレッドがあります。メッセージを受信するたびに、何らかの作業を開始します。そのスレッドの実行手順は次のとおりです。

アプリケーションを使用していくつかのテストを行ったところ、GetMessage 関数がメイン スレッドに依存していることがわかりました。これは、メイン スレッドが何らかの作業を行っている間、メッセージが受信されるのを待っているにもかかわらず、スレッドの GetMessage 関数が返されないことを意味します (メッセージは、PostThreadMessage 関数を使用してさらに別のスレッドによって送信されます: PostMessage( MyThreadId、WM_MyMessage、0、0))。

メイン スレッドが作業を終了するか、Application.ProcessMessages メソッドが呼び出されたときにのみ、GetMessage が返され、スレッドが作業を開始します。この種のスレッド間通信を実装することで、スレッドが独立して動作することは確実であり、スレッドに直接送信されたメッセージの受信がメイン スレッドに依存するとはまったく予想していませんでした。

テストを実行するために、メイン スレッドで WaitForSingleObject 関数を使用し、イベントを数秒間待機しました。これは、別のスレッドからメッセージが送信されたにもかかわらず、自分のスレッドが何も機能していないことに気付いたときです。WaitForSingleObject 関数が最終的に待機を終了し、メイン スレッドがアイドル状態になると、スレッドの GetMessage 関数が返されました。

誰かがなぜこのように機能するのか説明してもらえますか? その回避策はありますか？スレッドが独立してメッセージを受信できるようにしたいと考えています。私のスレッドはすべてメインスレッドによって作成されます。これが理由でしょうか？

事前にご協力いただきありがとうございます。

マリウス。

Mghie、あなたはまったく正しかったです (最近、あなたは私にメッセージを送信するのを手伝ってくれました。覚えているかもしれません)。あなたが示唆したように、 GetMessage はすぐに戻りますが、実際にはメインウィンドウメソッドの呼び出しでスレッドがハングします:

FOnCommEventMethod はオブジェクトのメソッドであり、'procedure (EventMask: Cardinal) of object;' として宣言されています。(このスレッドはシリアル ポート イベントを処理します)。この場合、FOnCommEventMethod には、メイン フォーム クラスに属するプロシージャが割り当てられています。メソッドがスレッドによって呼び出されると、メイン スレッドが作業を終了するのを待ってスレッドがハングします。

どうして？ご覧のとおり、Synchronize() メソッドを使用してこのプロシージャを呼び出していません。したがって、スレッドがメインスレッドと同期しているとは思いません。それは暗黙のうちに起こりますか？ところで、メインのスレッド以外の他のスレッドからは GUI コンポーネントにアクセスしてはならないことを理解しているので、Synchronize メソッドを使用する必要がありますが、現在は簡単なテストを行っているだけです。

WaitForSingleObject の件名に戻ると、私はそれを使用すべきではないことを知っていますが、(偶然にも) 問題に気付いたおかげで、それは単なるテストでした。

ご協力いただきありがとうございます。あなたが私を助けてくれなかったら、私はおそらくメッセージを取り除き、代わりにイベントを使用するでしょう.そして最終的に、それが理由ではないことに気付くでしょう:-)。

メッセージキューを作成するために Getmessage() の前に peekMessage ステートメントが必要なのはなぜですか?

ここで頭を悩ませています。アプリケーションの WPF コンポーネントのパフォーマンスの問題を調査しています。

私たちの .net アプリケーションは非常に大きく、ほぼ完全に Windows フォームです。新しいイニシアチブの一環として、コア コンポーネントの 1 つをリッチな WPF UI で書き直しました。多くの WinForms<-->WPF 相互運用がこのことと一緒に行われています。

ANTS プロファイラーで遅い操作をプロファイリングすると、関数 UnsafeNativeMethods.IntGetMessageW 内で多くのアクティビティが発生していることがわかります。ANTS は、すべてのビジネス ロジックと wpf レンダリングを組み合わせたものと同じくらい多くの CPU アクティビティをレポートします。サイクルを使用しているその関数のマネージ コード ダウンラインはありません。

私は win32 プログラミングに特に精通しているわけではありませんが、そのコンテキストでのメッセージ ループの基本は知っています。ここで見ているのは、手動で行うものではありません。コードのどの時点でも、基になるメッセージループ自体や、WPF ディスパッチャーでアクセスできるより複雑なものと直接対話していません。

ここで問題となっている WPF コンポーネントは Window から継承して記述されており (つまり、単なるコントロール/ユーザー コントロールではありません)、このコンポーネントの古い WinForms バージョンで ShowDialog を呼び出していた上位レベルのロジックから ShowDialog を使用して表示します。WPF コンポーネント内で使用した WindowsFormsIntegrationHost コントロールがいくつかあり、WPF で書き換えることができなかった一部の既存の部分との互換性を維持します。

私はこれを何日も調査してきましたが、続けるべきことがたくさん見つかりませんでした。入力メッセージ (マウスとキーボード) について話している漠然と関連する投稿を見つけ続けていますが、それを確認するために何ができるかわかりません。私はすでにコードを解体して、可能なすべてのマウス/キーボード操作を削除しようとしました。

主に、このコード行が完全に分離されており (実際に私たちのコードから来ていると指摘できるものの親または子ではない)、それが何をしているかについて完全に不透明であるため、どこにでも行くのに苦労しています。

ここに到達するための呼び出しのパスを示す ShowDialog 関数の ANTS 呼び出しグラフの画像を次に示します。

これは WPF の一部として実行しなければならないこと (WPF で記述した他のコンポーネントはこの動作を表示しませんが) である可能性があること、またはこれは ANTS プロファイラーの非常に奇妙なバグであることを完全に認識していますが、この時点で、何らかの方法で確認する必要があります。誰かがここで何が起こっているか、または何が起こっているのかを教えてくれたり、自分でそれを理解できる方法を教えてくれたりしたら、あらゆる種類の良いカルマをあなたに向けます.

更新：以下のいくつかの議論に応えて、ANTSからの別のビューがあります-これは、私が抱えている混乱をよりよく示しています（これは、「CPU時間」モードのANTSビューです）。私は急いでコードの一部を検閲しましたが、システム関連の機能は一切検閲しませんでした:

ご覧いただきありがとうございます。

バックグラウンド プロセスとして生成されたプロセスがありますが、何らかの理由でバックグラウンドでメッセージ ボックスが表示されるようです。そのため、プロセスがハングし、メッセージを取得できません。

WinDbg またはその他の方法でこのメッセージのテキストを取得する方法を誰か教えてもらえますか? これは、Windows Server 2008 x64 上の x64 ネイティブ c++ プロセスです。

「ぶら下がっている」スレッド (0) のスタックの一番上は次のとおりです。

ありがとう！

コンボボックス（c ++、win32 api）のデフォルトの動作を変更したい。編集コントロールに何かが入力されたときにコンボボックスをドロップダウンさせますコンボボックスがリスト内の最初の一致を検索して選択し、選択した文字列を編集コントロールに入力するというデフォルトの動作を避けたいです。GetMessage（）を使用して、メッセージキューからそれぞれの（LB_SETCURSELなど）メッセージをキャッチすることで、この動作を抑制できますか？

誰かがそれを行う方法について別の考えを持っていますか？

ミヒベックに挨拶

のような標準のWindowsAPI関数を使用してJavaキャンバスからテキストをキャプチャすることは不可能なので、そのようなJavaキャンバス内にメソッドをフックして、実際にキャンバスに描画される前にテキストをキャプチャする方法GetMessage()があるかどうか疑問に思いました。drawText()誰かがこれを解決する方法を知っていますか？Javaで書かれたソリューションも受け入れられます。どんな提案でもいいでしょう、ありがとう。

編集：外国のキャンバスハンドルを盗んで自分のキャンバスに設定することは可能ですか？したがって、外国のアプリケーションは、もはやそのキャンバスに描画するのではなく、私のなりすましのアプリケーションに描画します。このようにdrawText()して、アプリケーションでメソッドを簡単にオーバーライドできます。

DSPACKコンポーネントライブラリを使用してDelphi6で記述されたDirectShowフィルターがあります。これは、私も書いた外部の協力プロセスからソースフレームを受け取るプッシュソースビデオフィルターです。

FiltersのFillBuffer（）呼び出しを呼び出すワーカースレッドが作成されて実行されると、グラフが起動したときに、そのワーカースレッドから最初に行うことは、AllocateHWND（）を使用して非表示のウィンドウを作成し、外部を含むWM_COPYDATAメッセージを処理することです。生成されたフレーム。スレッドが破棄される直前に、非表示のウィンドウを破棄します。つまり、非表示のウィンドウは、FillBuffer（）を呼び出すワーカースレッドの実行コンテキストで作成および破棄されます。私の意図は、FillBuffer（）がWM_COPYDATAまたはWM_QUITメッセージを待機するときにブロックすることです。外部の協力プロセスは、WM_COPYDATAメッセージと非表示のウィンドウのWndProcc（）へのハンドルを使用して、フレームをフィルターに送信します。ピンのInactive（）メソッドのオーバーライドにWM_QUITメッセージを投稿します（そのヒント@RomanRに感謝します）。

私の質問は、このシナリオでは、FillBuffer（）呼び出しからPeekMessage（）またはGetMessage（）を呼び出しても安全ですか？または、DirectShowグラフの実行のコンテキストでこれが発生することから発生する可能性のある潜在的な落とし穴はありますか？また、ここでの私の全体的なアプローチに、考慮する必要のある欠陥がありますか？

何らかの理由で、GetMessage() ループが終了した直後に「無効なウィンドウ ハンドル」エラーが発生しますが、HWND を渡していないのに、どうしてこのエラーが発生するのでしょうか? :s

このアプリ以外で使用していて、このエラーが発生しないため、ShowError に問題はありません...

PostMessage、などを巧みに使用してLIFOGetMessageメッセージをキューに入れることは可能ですか（送信者と受信者の両方のメッセージループが連携していると仮定）、または独自のソリューションをロールする必要がありますか？

ユースケースについて疑問がある場合は、アイコンの読み込みです。常に、最後に要求されたアイコンを最初にロードする必要があります。:)