問題タブ [window-messages]

Mac OS X 上の Windows の PostMessage/SendMessage に相当するものは何ですか?

私は最近、Mac 開発を始めました。私の経験のほとんどは Windows と nix から来ています。

ウィンドウをフックして、マウスのクリックやキーボードの押下をシミュレートしたい。また、GetWindowText のような関数や、ウィンドウから特定のテキストを取得できる関数を見つけられるようにしたいと考えています。

デフォルトのコンテキストメニューを持つハンドラー（ ）を持つCWnd派生クラスがあります。このクラスは、私のアプリケーションのいくつかの場所で使用されています。 WM_CONTEXTMENUOnContextMenu

それが使用されている場所のいくつかはWM_CONTEXTMENU、親レベル（ウィンドウの親）でも処理します。基本的に、デフォルトのコンテキストメニューを上書きします。

派生クラス内にいるときはCWnd、基本的に、他の誰か（ウィンドウの親）がコンテキストメニューを処理したかどうかを知りたいです。

例えば：

Win32 / MFCフレームワークを介して可能ですか？

WM_MSO_BROADCASTCHANGE の値は何ですか? また、次回はどのようにそれを判断するのでしょうか?

これは、Windows プログラミングに関する一般的な質問のようなものです。

Window メッセージは「信頼できる」ものですか?

例(これらは単なる例です):

• カーソルが画面に入る前にが起こると確信できますか?WM_MOUSEMOVE

• デバイスが挿入された場合にメッセージが表示されると確信できますか?WM_DEVICECHANGE

• ウィンドウがフォーカスを失った場合にメッセージが表示されると確信できますWM_KILLFOCUSか?

または、言い換えると:適切なタイミングで適切なメッセージを受け取ることができると確信できますか? または、明らかに文書化されていない理由でメッセージを見逃す可能性がある場合に備えて、常に防御的にコーディングする必要がありますか?

例：

• ファイルシステムフィルタードライバーがファイル操作または変更通知を「見逃さない」ことが保証されています（AFAIK）。

• 対照的に、ReadDirectoryChangesWが通知を見逃さないという保証はありません。実際、バッファがオーバーフローすると、かなりの数が見落とされる可能性があります。

ノート：

敵対者に対する状況について話しているのではありません (たとえば、誰かがウィンドウ プロシージャをハイジャックしたり、フック/フィルターをインストールしたりするなど) 。それはほとんど保証を無効にするでしょう。自分のコードを制御できると仮定して、SendInputランダムなバッファ オーバーフローが発生した場合や、誰かが

私はプロセスのIDを持っています。このプロセスは、メイン ウィンドウを持つアプリケーションです。メイン ウィンドウに WM_CLOSE を送信して、このアプリケーションを閉じようとしています。を使用してメイン ウィンドウを検索していますEnumWindows。

問題は、私が閉じようとしているこのアプリケーションが常に閉じないことです。マルチスレッドアプリケーションです。以下に示す同じ方法を使用すると、メモ帳と Calc が常に閉じます。しかし、Calc.exe の場合でも、同じウィンドウに多くのハンドルが返されるため、正しく機能しているかどうかはわかりません。

スレッドがウィンドウへのハンドルを取得していて、このハンドルが何らかの形で破損する可能性はありますか? それともGetWindowThreadProcessId(hHwnd,pPid)、コールバックで他の関数を使用するべきではありませんか?

私はアイデアがありません。どんな助けにも感謝します。ありがとう。

コードスニペット：

TL;DR - Spy++ ツールは実際にプロセス リストをどのように構築するのですか?

ステージ

MFC デスクトップ アプリケーション (Windows XP で実行) がハングしており、ユーザー入力に反応しなくなりました。ただし、alt-tab で切り替えると再描画されます。( 、 などは受信WM_SETFOCUSしWM_ACTIVATEます。マウスやキーボードのメッセージは受信しないようです。)

アプリがどこかでハングアップしているため、いくつかのプロセス ダンプを取得しましたが、これまでのところほとんど役に立ちませんでした。入る：

スパイ++

Spy++ を使用して、このアプリケーションが処理していると思われるウィンドウ メッセージに関する上記の情報を見つけました。これを行うには、 Windows ビュー を開き、アプリケーション Window を選択し、Messages プロパティで選択した : を選択Windows of same processしMessages to ViewますSelect All。

ただし、最初に Spy++のProcesses View を開いてこのプロセスのすべてのメッセージを表示しようとしたところ、このプロセス リストにアプリケーションが表示されませんでした。アプリが正常に動作している別のPCでクロスチェックすると、Spy++のプロセスリストにもプロセスが正常に表示されます。

プロセスが Spy++ の Process Viewに表示されていないが、アプリのメイン ウィンドウが Windows ビューに表示されているという事実から、不正な動作をしているアプリについて何かを推測できますか。メイン ウィンドウが表示されているプロセスが、Spy++ のプロセス ビューに表示されないのはなぜですか?

プロセスは、タスク マネージャーと Visual Studio 2005 の [プロセスのアタッチ] ウィンドウに表示されます。

アプリが現在ハングしているシステムは Windows XP SP2 システムであり、Visual Studio 2005 に付属の Spy++ ユーティリティを使用しました。

この動作は時折繰り返されますが、アプリが数日間実行された後にのみ発生します!

ユーザー入力に反応しない MFC Visual-C++ アプリケーションがあります。

(注: 現在、1 台のマシンでのみ確認されています。この動作はときどき再発しますが、アプリを数日間実行した後でのみ発生します!)

アプリケーションは、Alt-Tab (またはタスク バー) で切り替えると再描画されますが、たとえば、タイトル バーをクリックしてメイン ウィンドウをアクティブにすることはできません。

WinDbg を使用して既に 4 つのダンプをプルし、アクティブな命令を確認しました。私たちは常に、メイン スレッド (GUI スレッド) 内でコードの再描画などを行っていました。私たちは間違いなくモーダル メッセージ ループに陥っていた/していないので、メイン スレッドのスタックは常に「OK」に見えました。(ほとんど/すべてのワーカー スレッドはアイドル状態で、何らかのイベントを待っていましたが、疑わしいコードもありませんでした。)

Spy++で問題を調査すると、この別の質問でも指定されている動作が見られます。つまり、ペイントとアクティベーション メッセージを取得しているように見えますが、ユーザー入力はアプリケーションにルーティングされません。画面にアプリケーションウィンドウがあり、それを選択してメインウィンドウのメッセージを表示すると、

「一般的な」「参照」メッセージのみが表示され、他には何も表示されません

さらに掘り下げて、プロセス全体のすべてのメッセージを選択すると、

これが私たちが見るものです：

アプリは明らかに 1 つの非表示のサブウィンドウ (00CB09F0) でのみメッセージを処理しており、そこには1 秒あたり 200 の WM_PAINT メッセージの一定のストリームが表示されます。

通常、このサブ ウィンドウはメッセージをまったく処理していません (Windows がメッセージを送信するときの WM_PAINT などの更新を除く)。これは通常、描画領域として使用され、描画はその親 (010A09B8) ウィンドウの WM_TIMER メッセージによって行われます。(ただし、この WM_TIMER メッセージはハングしているアプリにも表示されません。)

プロセス エクスプローラーに表示されるパフォーマンス プロファイルは次のようになります (100% カーネル時間、多かれ少なかれ):

WM_NOTIFY メッセージは、インプレースの「ツール ヒント」(メッセージ バルーン) やその他のコントロール通知によく使用されますが、TFrame にコントロールを配置すると、これらのコントロールに対して WM_NOTIFY メッセージは発生しません。これらのメッセージがフォームに送信されなくなったのはなぜですか?どうすればよいですか?

Windows 7 で C# Windows Forms プログラムを使用していますが、どの Windows プログラムにも当てはまると思います。

プログラムのメイン フォームは画面全体をカバーし、Topmost プロパティが設定されています。ただし、たとえば、[スタート] キーをクリックして [スタート] メニューを開くと、タスクバーと [スタート] メニューが [常に手前に表示] フォームの上に表示されます。

これが発生し、フォーム/ウィンドウが最上位のウィンドウ (または Z オーダーの最上位) ではなくなったときに、フォーム/ウィンドウに送信されるウィンドウ メッセージ (WM_) はありますか? WndProc を使用してキャッチしたいと思います。

ありがとうございました

私の C# .NET 4 アプリケーションでは、WndProcいくつかのメッセージを処理するために使用していましたが、主にアプリケーションのフルスクリーンへのサイズ変更とフルスクリーンからのサイズ変更を扱っていました。

現在、ウィンドウが最大化された状態にサイズ変更されているか、最大化された状態からサイズ変更されているかを判断するだけですSC_MAXIMIZE（WM_NCLBUTTONDBLCLKWndProcを処理する必要がないことはわかっていSC_MAXIMIZEますが、をダブルクリックしてもメッセージが表示Form_ResizeされないようですWM_NCLBUTTONDBLCLKアプリケーションのタイトル バー。

ウィンドウを画面の上部に Aero スナップして最大化すると、上記のメッセージのいずれも表示されないため、Aero Snap を使用してウィンドウを最大化すると、特定のロジックが適用されないことに気付きました。ウィンドウが右または左ではなく画面の上部にスナップされている場合、またはウィンドウが最大化された位置からスナップされていない場合にのみ、メッセージを処理したい。

Aero Snap に関連するウィンドウ メッセージが見つかりませんでした。これらのメッセージの参照を知っている人はいますか?