3

参考までに、この記事で概説されているウィンドウ スーパークラス メソッドを使用しています。特定の問題はWM_NOTIFY、スーパークラスのベース コントロールからのメッセージを処理する場合 (つまり、カスタム描画用) に発生します。メッセージを親ウィンドウから反映するか、独自のウィンドウを親として設定する必要があります (CREATESTRUCT 内でWM_(NC)CREATEベースに渡されます)。クラス）。スーパークラスが 1 つしかない場合、このメソッドは正常に機能します。スーパークラスをスーパークラス化すると、問題が発生します。現在、3 つの WindowProc が同じ HWND で動作しています。WM_NOTIFYメッセージ (または上記の親トリックから自分自身に送信される) は、常に最も外側の (最も派生した) WindowProc に移動します。それらが内部スーパークラス向けのメッセージ (基本メッセージは最初のスーパークラスに送られることになっている) なのか、外部スーパークラス向けのメッセージ (内部スーパークラスからのメッセージは外部スーパークラス向け) なのかを知る方法はありません)。これらのメッセージはすべて、同じコントロール ID を持つ同じ HWND から送信されるため、区別できません。継承の各レベルをカプセル化する新しいウィンドウを作成せずにこれを解決する方法はありますか?

テキストの壁について申し訳ありません。説明するのは難しい概念です。これが図です。

単一のスーパークラス:

SuperA::WindowProc() -> Base::WindowProc()---\
             ^--------WM_NOTIFY(ベース)--------/

スーパークラスのスーパークラス:

SuperB::WindowProc() -> SuperA::WindowProc() -> Base::WindowProc()---\
             ^--------WM_NOTIFY(ベース)--------+-----------------------/
             ^--------WM_NOTIFY(A)-----------/

2 番目のケースのWM_NOTIFYメッセージはすべて同じ HWND とコントロール ID からのものであるため、(Base からの) SuperA 向けのメッセージと (SuperA からの) SuperB 向けのメッセージを区別できません。何か案は？

4

2 に答える 2

1

Borland は、親レベルでメッセージ ID を変更することにより、VCL でこれを回避しました。親ウィンドウが WM_NOTIFY メッセージを受信すると、メッセージ ID が定義されたオフセット (CN_BASE) だけインクリメントされ、メッセージが指定する子ウィンドウにメッセージが直接渡されます。子ウィンドウ プロシージャ (および子のサブクラス) は、(CN_BASE + WM_NOTIFY) メッセージを検索し、元の WM_NOTIFY データにアクセスできます。同じ手法が WM_COMMAND メッセージにも適用されます。コードで同様のことを試してください。

于 2010-04-30T00:37:47.863 に答える
1

当然、コントロール (オリジナル?) は PARENT にメッセージを送信しています。おそらく、これらを傍受し、元のコントロールに戻しています。もちろん、外側のレイヤーはこれらを最初に確認します（処理したくない場合は、それらを渡すことができます）。

どのような種類の NOTIFY メッセージを傍受したいか、またはその理由については述べていません。しかし、親プロセスでそれらを制御して送り返すことができるようになったので、メッセージを変更してみませんか。独自の NMHDR 構造体をロールし、メッセージとデータを埋め込み、スーパー クラスのレベルの識別を追加します。スーパークラスでは、必要なものを剥がし、不要なものを再フォーマットして送信します。

それは少し乱雑に聞こえます。そのレベルでは、基本に戻って独自の共通コントロールを作成する傾向があります (もちろん、実際に何をしようとしているかによって異なります)。

于 2009-12-05T07:39:20.267 に答える