Библиотека содержит классы и интерфейсы для определения шаблонных коллекций, которые, в свою очередь, дают пользователю возможность создавать строго типизированные коллекции. Они обеспечивают большее удобство и высокую производительность работы с данными, чем обычные типизированные коллекции.
class CControl : public CObject
{
public:
int ПозицияХ;
int ПозицияY;
int Длина;
int Ширина;
color ЦветОсновы;
color ЦветБордюра;
int ТолщинаБордюра;
}
以上のことから、structure要素は特定のダイアログコントロールであり、それ自身のプロパティを含み、ネストしたコントロールを含むことができることが理解できる。このようなユニバーサル・コントロールの特性は、開発者の想像力によってのみ制限される。
もちろん、この構造を避けて、コントロールのプロパティを多次元配列 で記述することもできるが、コントロールのどのインデックスにどのプロパティが格納されているかを明確に覚えておく必要があるため、初期の費用対効果は良くない。また、配列に異種データを含めることはできません。手続き型プログラミングにおける制御要素の記述は、構造体を通じてのみ可能であることが判明した。すなわち、構造体要素は、具体的なコントロール、すなわち、ダイアログの具体的なオブジェクトとそのプロパティである。
標準ライブラリのIncludeフォルダの中にGenericという フォルダがあり、その中にKey-Value型のインターフェースを実装した CHashMapクラスがあります。
一つのオブジェクトは、任意の型の値の集合を持つことができる。マップツリーは実行に時間がかかるものの、かなり高速に動作します。
プロパティの記述にも使えるかもしれないので、一般的に試してみるべきでしょう。
または、このライブラリの他のクラスタイプを使用してください。
つまり、画素の配列に等しい配列を格納し、この配列に情報（あなたの場合、「どの関数番号」を使って処理するか）を格納することを提案しているのだと読み替えてください。?
そして、その逆、つまりインターフェースとチャートをリンクさせることもあるでしょう。例えば、時間や価格と厳密に連動したボタンを作ること。
テーブル、タブ、メニュー、ホイッスルをすべて備えた独立したGUIをすぐに書くことができます。C#でも、BASICでも。そして、チャートの内側は、外部アプリケーションにとって大きな問題です。
それから、なぜインターフェースとチャートを結びつけるのか？
何しろ、タイムスタンプや価格など、あらゆるデータを関連する機能から直接取得できるのですから。
つまり、画素の配列に等しい配列を格納し、この配列に情報（あなたの場合、「どの関数番号」を使って処理するか）を格納することを提案しているのだと読み替えてください。?
と聞かれれば、そんなことは言っていない。私は全く何も提案していません))。ただ、私の意見を少し述べただけです。反対するのは自由です。
原理的には、型を一般化することは可能である。オブジェクトのプロパティの大半がint型であれば、何も悪いことは起きないという結論に達しました。それ以外の（ダブルはグラフィカルなオブジェクトのプロパティには実質的に存在しない）省略型は、簡略化のために却下した。メモリの「オーバーラン」なんて、考える意味がないくらい些細なことです。もちろん、プロフェッショナリズムのためには、そんな冒涜的なことはできませんが)))。しかし、これは21世紀であり、私は焚き火に脅かされることはありません）。
モノの名前を数字にして、一般的なモノの性質のシリーズに入れました。
唯一、別の種類のデータが必要だったのは、制御パラメータでした。このカーネルは、パラメータのプロパティを保存し、値自体を文字列型に格納します。
ヒント：「コントロールエレメントパラメーター」とは、コントロールエレメントで管理されるパラメーターのことです。すべてのコントロールとそのすべてのプロパティを含むグローバル配列は、コントロールのすべての異なるプロパティの合計に等しい次元の深さを持っていることが判明した。つまり、コントロールの一部のプロパティが不要であっても、配列は常に一様であるため、これらのセルはこの配列に含まれることになる。
しかし、驚くべきは、その配列自体の均一性です。この点で、構造体を使うことは正当である。この場合、各プロパティは、ユニオンを含めて、それ自身の型によって記述することができるからである。
構造体を使うことで、プロパティの保存が本当に簡単になり、1つのタイプに限定したり、何かをあきらめたりする必要がありません。文字列から他のデータ型への 変換に悩まされることもなく...。構造体は、こうした制約を最初からすべて取り払ったものです。
このグローバル配列には、プロパティと座標そのものに加え、要素の従属系も格納する必要がある。図面のCaptionオブジェクトが変更された場合、ボタンはヘッダーフィールドに配置されているため、ボタンも再描画する必要があります。そのため、いずれかの「中」コントロールが変更された場合、その上にあるものはすべて再描画されるはずです。Peterさん、オブジェクトの依存関係はどのように保存しているのですか？すべてのコントロールとそのすべてのプロパティを含むグローバル配列は、コントロールのすべての異なるプロパティの合計に等しい次元の深さを持っていることが判明した。つまり、ある要素に不要な特性があったとしても、配列は常に一様であるため、これらのセルはこの配列の中に存在することになる。
しかし、驚くべきは、その配列自体の均一性です。この点で、構造体を使うことは正当である。この場合、各プロパティは、ユニオンを含めて、それ自身の型によって記述することができるからである。
構造体を使うことで、プロパティの保存が本当に簡単になり、1つのタイプに限定したり、何かをあきらめたりする必要がありません。文字列から他のデータ型への 変換に悩まされることもなく...。構造体は、こうした制約を最初からすべて取り払ったものです。
...ピーター、オブジェクトの依存関係の構造はどのように保存しているのですか？
それから、なぜインターフェースとチャートを結びつけるのか？
結局のところ、同じタイムスタンプや価格などのあらゆるデータを、関連する機能から直接取得することができるのです。
アプリケーション・インターフェース（ユーザーが操作するもの）が単一のウィンドウに限定されないことによる。
トレーディングの話ですよね？
まあ、チャート上のインタラクティブ要素の配置（とその束縛）は、外的手段ではほとんど解決できないのですが。
ここでも外部ダイアログ／フォームが描きやすくなっています。しかし、チャート内部の要素は、端末と具体的なチャートの仕様が分からないとほとんど描けない。
コアはマトリックスです。オブジェクトの全プロパティが含まれる。
マトリックスはループの入れ子であり、ループの入れ子は時間である。イマイチ、皮肉もなく、ただ論理的に推論しているだけ。
Peter: コアは、要素のプロパティのグローバルマトリクス、要素の値のグローバルマトリクス、依存関係のグローバルマトリクス、ピクチャのグローバルマトリクスから構成されています。
さらに特性を追加する必要がある場合は、行列の次元を増やすことになる。
セルには名前がないため、プロパティは厳密にインデックスによってアクセスされる。
少なくともフィールド名には構造体でアクセスできる。
ピーター、あなたは...ジャイアント...
私などは、このように捉えています（簡略化）。
事実上の「クラス」は、グローバル配列の中の特定の文字列であり、より「人間的」な顔を持っています。クラスは、インデックスではなく名前でアクセスできる理解しやすいプロパティのセットを持つ、独自のデータオブジェクトを作成するように設計されています。クラスは普遍的な型コンストラクタに過ぎない。
そこで、ほとんどすべてのコントロールが持っている、最も一般的なプロパティを含む基本的なコントロールを作成しましょう。
それを元に特殊なオブジェクトを作ることができます。
つまり、後続の各コントロールタイプは、ベースタイプに必要なプロパティを追加するだけである。
そして、先ほど書いたように、基本的なプロパティはベースコントロールに格納されているので、コントロールのカーソルを「打つ」というトラバースは、CControlという 一つのデータ 型をチェックすることで行われるのです。目的のオブジェクトを見つけると、プログラムはすぐにそのオブジェクトのプロパティにアクセスできます。プログラムポイントはすでにオブジェクト自体にあるので、ちょうどループの中でプログラムが目的の配列行にいるのと同じです。