0

最初のwinapiUIを進めると、WinMainファイルにHWND変数の大きくて不快なスタックを作成していることに気付きます。

HWND foo;
HWND bar;
HWND baz;
HWND etc;

int WINAPI WinMain(...) {}

もちろん、これらの変数はファイルの残りの関数（たとえば、メッセージループ）で使用されるため、アクセス可能である必要があります。

私の比較的小さなUIの場合、30個のHWNDのようなものを積み上げて、それらが可視スコープ内にあるようにします。これは私がそれを間違っていることを非常に疑わしく思います。

これは何が起こっているべきか、それともこれを整理するためのより実用的な方法がありますか？

4

2 に答える 2

1

プログラムが何であるかに応じて、いくつかの解決策があります。

  1. これらのハンドルはすべて、のような1つまたは複数のコンテナに入れることができますstd::vector。
  2. クリスが提案するようにそれらをマッピングすることができます。
  3. プログラムが大きくなった場合は、それらを論理ユニットに編成することをお勧めします。たとえば、これらのウィンドウの15がロジックの半分に使用され、残りの15が別の半分に使用される場合（たとえば、タブ内のコントロール）、これらのコントロールを何らかの方法（ファイル、クラス、最も論理的に適合するもの）でグループ化することができます。 ）。
于 2012-11-06T02:09:24.507 に答える
0

メインプログラムに必要なHWNDは1つだけで、それはメインウィンドウ用です。

APIは単一のメインウィンドウを必要としませんが、それが最も一般的です。また、ユーザーの観点から、アプリケーションがいくつかの明らかに独立したウィンドウを提供している場合でも、プログラムにメインウィンドウを含めることをお勧めします（非表示にすることもできますが、グループ化を提供します）。

他のウィンドウは、メインウィンドウ（その中）の子、またはメインウィンドウによって「所有」されているウィンドウのいずれかになります。一般に。特に、初めてのWindowsプログラムの場合。:-)したがって、これらのウィンドウに個別の変数は必要ありません。ウィンドウが何かに反応する必要があるときはいつでも、それはウィンドウへのメッセージです。これは、関連するウィンドウハンドルを引数として関数を呼び出すことを意味します。

すべての子ウィンドウは一意の整数IDを持つことができ、それがそれらを追跡する1つの方法です。

ただし、先に進むと、状態を各ウィンドウに関連付ける必要があります。これを行う最も簡単な方法は、Windowsの「サブクラス化」APIを使用してポインターを各ウィンドウに関連付けることです。次に、ウィンドウプロシージャの呼び出しを、関連付けられたC++オブジェクトのメソッドにルーティングできます。さまざまなメッセージをさまざまなメッセージ処理メソッドにさらにルーティングでき、それぞれがウィンドウの状態にアクセスできます（これはこのC ++オブジェクトだけです）。

于 2012-11-06T02:58:56.437 に答える