ここでの両方の答えは良いですが、私が本当に興味深いと思う部分を省略しました (直接尋ねなかったが、とにかく興味があるかもしれないいくつかを含む)。
コントロールの描画
理想的には、先に進んでコントロールの通常のインスタンスを作成するだけです。ボタンのようなものが欲しいですか？実際のボタンを作成します。トリッキーなことは、ボタンのように動作するのを止めることです: 実際に「クリック」するのではなく、クリックして移動のためにアクティブにする必要があります。
これに対処する 1 つの方法 - 問題のコントロールが 'HWND ベース' (たとえば、ボタン、編集、静的、リストボックス、ツリービューなどの標準ウィンドウ セット) であると仮定すると、コントロールを作成してからサブクラス化することです。それ - すなわち。wndproc を SetWindowLongPtr(GWLP_WNDPROC, ...) でオーバーライドして、デザイナー コードがマウスとキーボードの入力をインターセプトし、それを使用して移動を開始できるようにします。たとえば、マウス入力を実際のボタン コードに渡す代わりに、代わりに「クリック」イベントとして解釈します。
サブクラス化の別の方法は、ボタンの上に非表示のウィンドウを配置して入力をキャプチャすることです。入力をインターセプトするという同じ考え方ですが、実装が異なります。
上記は、マネージド (VB.Net、C#) コントロールとアンマネージド (C/C++) コントロールの両方に適用されます。どちらも本質的にストック ウィンドウ HWND です。マネージ バージョンには、基になるアンマネージ コントロールに渡すマネージ ラッパー コードが含まれているだけです。
.Net VB より前に使用されていた古い (事前に管理されたコード) ActiveX コントロールは、まったく別の球技でした。ActiveX コンテナーとその中の ActiveX コントロールの間にはかなり複雑な関係があり、プロパティ、イベント、描画などのネゴシエーションなどを処理する多くの COM インターフェイスがあります。(ActiveX コントロールが入力を受け取り、独自の HWND を持たずにそれ自体を描画できるようにする一連のインターフェイスのイベントがあります。) ただし、この複雑さから得られる利点の 1 つは、ActiveX コントロールには明示的な「デザイン モード」があることです。そのため、コントロールはその場合に適切に応答することを認識し、手順全体に協力できます。
フォーム自体...
したがって、基本的にコントロールは通常のコントロールです。では、フォーム自体は通常のフォームであると思いますか? - ほとんど。私の知る限り、デザイナーの子である別の HWND ベースのウィンドウです (そのため、クリップされ、その中でスクロールできます)。しかし、デザイナーはここで少し「不正行為」をしていると思います。通常、Windows は実際のトップレベル ウィンドウのタイトルバーと最小/最大ボタンのようなフレームしか描画しないためです。彼らがここで使用している正確なテクニックはわかりませんが、いくつかのオプションには以下が含まれる可能性があります。Windows の外観を模倣するために手動でペイントする。Windows の「テーマ」API を使用して、タイトルバーの断片に使用されるグラフィック要素にアクセスし、好きな場所にペイントできるようにします。または、おそらく可能性は低いですが、ウィンドウを「MDI子ウィンドウ」として設定します
ドラッグ可能なハンドル
ここでの最も簡単なアプローチは、デザイナーが、他のすべての要素の上にある、タイトル バーのない小さな正方形のポップアップ ウィンドウを 8 つ作成することです。これらのウィンドウは、クリックされると適切なサイズ変更コードを開始します。ユーザーがコントロールからコントロールへとクリックするとき、ドラッグ ハンドル ウィンドウを現在アクティブなコントロールに移動するだけです。(上記のすべてにおいて、Windows 自体が誰がクリックされたかを把握していることに注意してください。実際にマウスの座標を要素の四角形の座標と比較して、自分で計算する必要はありません。)
保存と再作成
アンマネージ C/C++ で使用される単純な Windows システム コントロールの場合は、比較的簡単です。コントロールと場所を記述する、よく知られたテキスト ベースのファイル形式 (.rc) があります。デザイナーにそれ (およびおそらく resource.h ファイルも) を吐き出させると、完了です。どの C/C++ プロジェクトでも、これらのファイルを取得してコンパイルできます。マネージ コード (C#、VB.Net) には、もう少し複雑なスキームですが、基本的な考え方は同じです。つまり、マネージド ツールが期待するスタイルで記述を書き出すと、マネージド ツールは喜んでそれをコンパイルして使用します。
(ActiveX コントロールは、ご想像のとおり、まったく別の話です。私が認識している標準形式はありません。そのため、データを使用するフォーム エディターとランタイムは密接に結びついています。 .Net VB6 より前のフォーム エディターは、VB だけが使用できるフォームを作成します。
フォームの再作成に関しては、.rc ファイルがある場合、ダイアログ リソースにコンパイルされます。Windows には、それらを再作成するためのサポートが組み込まれています。同様に、マネージ コード サポート ライブラリは、特定の形式からフォームを再作成する方法を知っています。どちらも基本的に説明を解析し、アイテムごとに適切なクラスの要素を作成し、適切なスタイル、テキスト、およびその他のプロパティを指定どおりに設定します。自分でできないことは何もしていません。単なるヘルパー ユーティリティ コードです。
フォーカスの処理
コンテナー内の HWND のコレクションについては、「テスト」モードであるか実際のアプリで実際に実行されているかに関係なく、フォームの作成を Windows または Winforms に処理させるかどうか、または各 HWND を自分で作成したかに関係なく、次の方法でタブ サポートを追加できます。メッセージ ループでIsDialogMessageを呼び出す: 詳細については、MSDN ページの備考セクションを参照してください。(WinForms はこれを行うことができますが、実際には独自のフォーカス処理を行うため、視覚的なスタッキング Z オーダーから独立したタブ オーダーを持つことができると思います。)
その他の探索事項...
Spy++ アプリ (SDK の一部、Visual Studio と共にインストール) と友達になりましょう。マネージドまたはアンマネージドの HWND を使用して何かを行う場合は、このツールの使用方法を知っておくことをお勧めします。Windows の任意の UI をポイントして、ツリーからどのように構築されるかを確認できます。さまざまなタイプの HWND。それを VB デザイナに向けて、実際に何が起こっているかを確認してください。(ツールバーの「双眼鏡」アイコンをクリックし、目的のウィンドウに十字線をドラッグします。)
また、デザイナーが吐き出すリソース ファイルも見てください。フォーム デザイナで微調整、移動、または編集できるものはすべて、これらのリソース ファイルのどこかにある項目に対応しています。それらのコピーを作成し、いくつかの設定を微調整してから、2 つのセットをファイル比較して、変更点を確認します。ファイル内のいくつかを手動で変更してみて (ほぼすべてテキストだと思います)、リロードして、デザイナーが変更を反映しているかどうかを確認してください。
その他の注意事項...
上記の多くは Windows に固有のものです。特に、Windows 独自のビルディング ブロック (HWND) を使用しているため、Windows 自体に難しい作業の一部を任せることができます。これにより、コントロール自体を再利用する機能が提供されます。設計時にモックアップを作成する必要がありません。他のコントロールへの入力をインターセプトして、動きやその他の必要なアクションをクリックしたり、自分で位置計算を行うことなくクリックされたコントロールを特定したりできます。これが、内部で HWND を使用しない他の UI フレームワーク (Flash など) のデザイナーである場合、代わりに
そのフレームワークの独自の内部機能を使用して同様の作業を行う可能性があります。
また、少なくとも最初のうちは、パレット内のコントロールの数を小さな有限セットに制限すると、はるかに簡単になります。コントロールをドラッグできるようにしたい場合 - たとえば。サードパーティのもの、または別のプロジェクトで使用したもの; 通常、最初にそのコントロールが使用可能であることをデザイナーが認識できるように、そのコントロールを「登録」する何らかの方法が必要です。また、ツールバーでどのアイコンを使用しているか、その名前は何か、どのプロパティをサポートしているかなどを発見する何らかの方法が必要になる場合もあります。
楽しく探検しましょう！
