RegisterWindowMessageを乱用するとリソースが枯渇する可能性がありますか？

Question

RegisterWindowMessage（）関数は、プロセス間で送信されるメッセージの登録にのみ使用されることが推奨されています。 1つのプロセス内で送信するためにメッセージが必要な場合は、範囲WM_APPから0xBFFFまで安全に選択できます。

しかし私たちのコードベースでは、RegisterWindowMessage（）が1つのプロセス内でのみ送信されるメッセージに使用されることがよくあります。これは、WM_APP..0xBFFFの範囲でメッセージ識別子を手動で配布する必要がないため、RegisterWindowMessage（）を使用することの単純さが認識されたために行われたと思います。

多くのアプリケーションが1台のマシンで実行され、RegisterWindowMessage（）によって返されるメッセージ識別子の範囲を使い果たす可能性のある異なる文字列でRegisterWindowMessage（）を呼び出すと、失敗を示す値を返しますか？ WM_APP..0xBFFFの範囲メッセージで十分である場合に、RegisterWindowMessage（）メッセージを使用する正当な理由は何ですか？

Answer 1

私見あなただけの自分にメッセージを送信する場合はRegisterWindowMessageを使用するための有効な理由はありません

あり

への（文書化）方法はありません登録解除アプリケーションが終了した後、メッセージを登録し、そのままになりますので、メッセージを原子テーブル内の再起動/ログオフまで（私はこの原子テーブルがどこに格納されているか正確には分からない、ウィンドウステーションまたはターミナルサーバーのセッションインスタンス）

Answer 2

あなた自身にメッセージを送るときにもRegisterWindowMessageを使用する必要がある理由はWM_APP + Nの範囲でメッセージをブロードキャストする馬鹿からあなたを守ります。

はい、これは起こります。

Answer 3

Spy ++はより有益なテキストを表示できるので、デバッグが少し楽になります。もちろん

<00129> 004F0DA0 S message:0xC2B0 [Registered:"AFX_WM_ONCHANGE_ACTIVE_TAB"] wParam:00000001 lParam:02B596E8 

で

<00058> 00330CA2 S message:0x0419 [User-defined:WM_USER+25] wParam:00000000 lParam:00000000 

比較、原則的にはメッセージIDのうち、実行する機会があります。一方、MFC Feature Packのソースコードには、RegisterWindowMessageへの52の呼び出しがあります。したがって、他のアプリケーションにはまだ16300個のIDが残っています。

Answer 4

RegisterWindowMessageを濫用すると、潜在的にウィンドウボックスが使用できなくなる可能性があります。これは特に、ウィンドウメッセージ名が動的に生成され、バグにより制御ウィンドウ外のメッセージの割り当てが発生した場合に当てはまります。この場合、Windowsステーション/デスクトップのグローバルアトムテーブルがいっぱいになり、User32.dll（基本的には、どのアプリも）を使用するプロセスは、ウィンドウの作成や起動に失敗します。

バグがありますControlOfsXXXXXXで始まるメッセージを登録するDelphi/Borland製品。XXXXはメモリアドレス（または他の動的修飾子）です。頻繁に開始され停止されるアプリケーションは、複数のControlOfsXXXXアトムを登録し、最終的にアトムスペースを使い果たします。以下のためのより多くの詳細は以下を参照してください

http://blogs.msdn.com/b/ntdebugging/archive/2012/01/31/identifying-global-atom-table-leaks.aspx

そして

https://forums.embarcadero.com/thread.jspa?threadID=47678