1

次のような MFC/C++ CView オブジェクト サブクラスを見ています。

BOOL CCustomView::CreateView(DWORD dwStyle,
                  CDocument * pDocument,
                  CWnd * pParent,
                  String title)
{
  ...
   CString className = AfxRegisterWndClass(CS_DBLCLKS,
                       ::LoadCursor(NULL, IDC_IBEAM));
   return Create(className, title, dwStyle,
         rect, pParent, -1, &context);
}

これについて私が気に入らないのは、MFC アプリケーション プログラミングでは通常のことかもしれませんが、ランタイム ウィンドウ クラス名が自分で選んだ名前ではないことです。後で、別の Win32 アプリケーションからこのウィンドウを見つけ、ウィンドウ クラス名でウィンドウを見つけたい場合、醜い "Afx:123:39843:39843" 文字列を使用する必要がありますが、実際には使用しません。これらのウィンドウ クラス名が変更されないことを期待できるかどうかを確認してください。ウィンドウ クラスを「CCustomView」に変更したいのですが、上記で作成したウィンドウ クラスと同じ動作を維持します。それ、どうやったら出来るの？

4

1 に答える 1

3

問題を解決するためのより良い方法があります。私が使用する典型的なプロトコルは次のとおりです。

  • RegisterWindowMessage両方のアプリケーションで使用するウィンドウ メッセージを登録します。メッセージ名には、一意にするために GUID を含める必要があります
  • アプリケーション A で、ウィンドウ ハンドルをすべての最上位ウィンドウ
    PostMessage(HWND_BROADCAST, registeredMsg, idIWantToFindYou, HWNDofA)
    に公開するために使用します。登録メッセージには複数の用途があり、登録するメッセージの数を制限する必要があるidIWantTofindYouため、メッセージのさまざまなコマンドを区別するために使用します。
  • 受信アプリケーション B は、送信側のウィンドウ ハンドルを取得し、接続を確立できます (たとえば、
    PostMessage(HWNDofA, registeredMessage, idHereIsMyHWnd, HWNDofB)

このメカニズムの利点は、応答しないプログラムの問題が発生しないことです。ただし、「接続」は即時ではないため、プログラム フローを変更する必要があります。または、 と を使用EnumWindowsしSendMessageTimeoutて、すべてのトップレベル ウィンドウをプローブすることもできます。

ウィンドウ クラスを使用する必要がある場合:

MFC によって割り当てられるクラス名は、同じ属性を持つウィンドウ クラスが再利用されるようにするためだけのものです。独自のウィンドウ クラスを使用する際の問題は認識していません。

したがって、次のように動作するはずです。

  • WNDCLASSまたはWNDCLASSEXに必要な属性を入力します
  • として使用DefWindowProcしますWNDPROC(これが MFC の機能です。MFCWNDPROCはウィンドウの作成時に設定されます)。
  • AfxRegisterClassまたはを使用RegisterClassして、ウィンドウ クラスを登録します。AfxRegisterClassクラスが既に登録されているかどうかを確認し、クラスが DLL から登録されている場合は、DLL がアンロードされるときにクラスを登録解除します。それ以外の場合、それらはほぼ同等です。
于 2012-09-16T16:47:40.527 に答える