При создании графического объекта функцией ObjectCreate() необходимо указать тип создаваемого объекта, который может принимать одно из значений перечисления ENUM_OBJECT. Дальнейшие уточнения свойств созданного объекта возможно с помощью функций по работе с графическими объектами.
...
Peterさん、あなた流のGUIライブラリをよく作ってくれましたね。しかし、出版する予定があるのなら、やはり別の技術に設計し直す価値があります。私はこれを支援し、ステップバイステップであなたのライブラリのすべての力を新しい方法で転送する準備が整いました。
アレクセイ、やってみたいことがあるとします。どうするつもりですか？無理な仕事です。
ピーター、私はおそらく、あなたの仕事の量のほんの一部も想像できないし、あなたが作った物の 全容を単に過小評価しているに過ぎないのだと思います。しかし!
いつものように、BUT!
プログラミングでなくても、どんなプロジェクトでも。
そもそも、作られたモノから抽象化する。つまり、行列や構造、クラスとして表現することはしない。ここでは、単純にOBJECT（コントロールエレメント、フォーム、インターフェイス全体など）の概念を受け入れることにします。オブジェクトの相互作用を構造的にレイアウトしてみるのです。何が造られているのかが一緒にわかったら、その上で規則性を明らかにしていこうと思います。原則的には、とっくに特定して統一的な扱いにしているので、特定する必要はなく、動作原理や目的を説明するだけです。次に、プロジェクト内のあるオブジェクトを別のオブジェクトに置き換えるだけです。もちろん、ゼロから書くよりずっと大変でしょう。でも、私たちの場合は目的が少し違うので、大筋で急ぐことはありません。しかし、マトリックスアルゴリズムからオブジェクトアルゴリズムへの変換に関する出版物は、初心者だけでなく、おそらく興味深いものでしょう。この作業の過程で、他の参加者が私たちに加わり、アイデアを共有したり、このアルゴリズムやあのアルゴリズムをもっと便利に実装するよう促してくれるものと確信しています。
いずれにせよ、アイデア自体は、まずアルゴリズムのフローチャートで表現する必要がある。
という提案をしました。しかし、それ以外でも可能です。すべては、あなたの希望と問題（共同作業）に対する考え方次第です。
ピーター、私はおそらく、あなたの仕事の量のほんの一部も想像できないし、あなたが作った物の 全容を単に過小評価しているに過ぎないのだと思います。しかし!
いつものように、BUT!
プログラミングでなくても、どんなプロジェクトでも。
そもそも、作られたモノから抽象化する。つまり、行列や構造、クラスとして表現することはしない。ここでは、単純にOBJECT（コントロールエレメント、フォーム、インターフェイス全体など）の概念を受け入れることにします。オブジェクトの相互作用を構造的にレイアウトしてみるのです。何が造られているのかが一緒にわかったら、その上で規則性を明らかにしていこうと思います。原則的には、とっくに特定して統一的な扱いにしているので、特定する必要はなく、動作原理や目的を説明するだけです。次に、プロジェクト内のあるオブジェクトを別のオブジェクトに置き換えるだけです。 もちろん、ゼロから書くよりずっと大変でしょう。でも、私たちの場合は目的が少し違うので、大筋で急ぐことはありません。しかし、マトリックスアルゴリズムからオブジェクトアルゴリズムへの変換に関する出版物は、初心者だけでなく、おそらく興味深いものでしょう。この作業の過程で、他の参加者が私たちに加わり、アイデアを共有したり、このアルゴリズムやあのアルゴリズムをもっと便利に実装するよう促してくれるものと確信しています。
いずれにせよ、アイデア自体は、まずアルゴリズムのフローチャートで表現する必要がある。
提案させていただきました。しかし、それ以外でも可能です。すべては、あなたの願望と問題意識（一緒に働くこと）次第なのです。
わかりました。自分にできることをやっていこうと思います。その解決策とアーキテクチャを解説します。でも、最終的に成功するかどうかはわからない。
これでカーネルにオブジェクトが配置されました。カーネルから取り出して、クラスに入れる必要がある。
1.Rectangle_label」（矩形ラベルの基本的なプロパティをすべて収容）、「Icon」、「Text」の3つの基本クラスを作成することになるでしょうね。これらのオブジェクトは、ほとんどすべてのコントロールに含まれています。
2.次に、子孫クラスのグループを作成します。それらは以下の基準で分けられるだろう。 a) パラメータを制御する要素 b) パラメータによって制御される要素。
3.クラスは、各要素の具体的なプロパティを記述することになる。
これらは、あくまで最初のアイデアです。間違っているかもしれない。
この方式では、要素クラス（継承者）は一度に3つの基底クラスのプロパティを含まなければならないため、継承はすぐに多重継承になってしまう。
わかりました。がんばります。その解決策とアーキテクチャを説明します。でも、最終的に成功するかどうかはわからない。
今は、カーネルの中にオブジェクトが整理されています。カーネルから取り出して、クラスに入れる必要がある。
1.Rectangle_label」（矩形ラベルの基本的なプロパティをすべて収容）、「Icon」、「Text」の3つの基本クラスを作成することになるでしょうね。これらのオブジェクトは、ほとんどすべてのコントロールに含まれています。
2.次に、子孫クラスのグループを作成します。それらは以下の基準で分けられるだろう。 a) パラメータを制御する要素 b) パラメータによって制御される要素。
3.クラスは、各要素の具体的なプロパティを記述することになる。
これらは、あくまで最初のアイデアです。間違っているかもしれない。
この方式では、要素クラス（子孫）は3つの基本クラスの特性を同時に含まなければならないため、継承は一度に複数回行われることになる。
では、ここで推論を。
"矩形ラベルの基本的なプロパティをすべて含む「Rectangle_label」、「Icon」、「Text」の3つのベースクラスを作成します。"- 古典的には、最初のオブジェクトは単に矩形またはRectと呼ばれ、2番目の一般化された画像は、まあ、第三は、別のプロパティで記述することができ、また、別のオブジェクトを作ることができます。作成されたデータ型が c++やmqlのクラスであることを示すために、CRectangle, CImage, CTextのように型名の前にCをつけるのが普通である。しかし、異種データを含むだけの単純な型は、構造体として作成する方が便利です。
まず最初に考えるべきは、LARGEコントロールの基本特性のすべてである。さらに、任意のプロパティを追加することも可能です。
"a)パラメータを制御する要素 b)パラメータによって制御される要素"- ここで解読が必要です。これらの記述の意味がわからない。
"最終的に成功するかどうか"-やはり成功すると確信したほうがいい。そうでなければ、始めないほうがいい。さて、ここで少し推論を。
1."Rectangle_label "は矩形ラベルの基本的なプロパティをすべて含んでおり、"Icon "と "Text "の3つの基本クラスを作成することになります。- 古典的には、最初のオブジェクトは、単に矩形またはRECTを呼び出す、第二一般化画像、よく、第三はどちらか別のプロパティロボによって記述することができますも白いオブジェクトを作成します。c++やmqlでは，作成されたデータ 型をクラスとして示すために，型名の前にCをつけるのが通例である（例：CRectangle，CImage，CText
2."a)パラメータを制御する要素 b)パラメータによって制御される要素"- ここで解読が必要です。これらの記述の意味がわからない。
"最後に成功があるのか"-やはり成功があると確信したほうがいい。そうでなければ、始めないほうがいい。1.最も基本的なクラスはGHObjest（基本グラフィックオブジェクト）です。x,y, x_size, y_sixe プロパティと、異なるタイプの座標バインディングがあるはずです。これらは、すべてのオブジェクトに共通する性質です。
2. その子孫は、CRec, CImage, CText。それらは特定の、固有の唯一の特性を持つ。
3.そして、ウィンドウ・プラットフォーム・クラスです。メニューウィンドウ、オプションウィンドウ、ダイアログウィンドウ、ダイナミックウィンドウがあります。そこには、特定のプロパティーが設定されています。
3.次に、エレメントクラスです。最大で50個あるかもしれません。それらは、1）パラメータ処理の方法によるもの、2）装飾的な方法によるもの、に分けられる。
これは良いきっかけになります。ライブラリではなく、マークアップ言語を作る必要があるのです。そうでなければ、何の意味もないでしょう？
ZS ほとんどのコントロールは、与えられたパラメーターで動作します。その目的の本質は、何らかのユーザーパラメータを制御することである。でも、それぞれのコントロールでやり方が違うんです。
付け加えると、パラメータのベースクラスとそのプロパティが必要です。例えばCParam。
1.最も基本的なクラスはGOBijest（Basic Graphical Object）です。x,y, x_size, y_sixe プロパティと、異なるタイプの座標バインディングがあるはずです。これらは、すべてのオブジェクトに共通する性質です。
2. その子孫は、CRec, CImage, CText。それらは特定の、固有の唯一の特性を持つ。
3.そして、ウィンドウ・プラットフォーム・クラスです。メニューウィンドウ、オプションウィンドウ、ダイアログウィンドウ、ダイナミックウィンドウがあります。そこには、特定のプロパティーが設定されています。
3.次に、エレメントクラスです。最大で50個あるかもしれません。それらは、1）パラメータ処理の方法によるもの、2）装飾的な方法によるもの、に分けられる。
これは良いきっかけになります。ライブラリではなく、マークアップ言語を作る必要があるのです。そうでなければ、何の意味もないでしょう？
ZS ほとんどのコントロールは、与えられたパラメーターで動作します。その目的の本質は、何らかのユーザーパラメータを制御することである。しかし、それぞれの要素でやり方が違う。
ちょっと脳みそが爆発しそうです...。))全部描かないと消化できないんです。)
ちょっと脳みそが爆発しそうです・・・。))全部描かないと消化できないんです。)
))何も...
CParam パラメータの基底クラスは、いくつかの子孫を持ちます。要は、管理項目のパラメータには一般的な性質と、具体的な性質があるということです。例えば、ボタンは制御パラメータ型がboolであり、ドロップダウンリストは「menu」型である。つまり、ボタンでは1/0を切り替え、リストでは限定された選択肢を提供します。例えばスライダーは、パラメータのタイプが "range"、つまり範囲です。他にもいくつかの種類があり、どれもユニークな特性を持っています。
したがって、ベースパラメータクラスの下位に位置するクラスも同様であるべきです。CBool", "CRange", "CMenu "のようなものです。
))何も...
CParam パラメータの基底クラスは、いくつかの子孫を持ちます。要は、制御される項目のパラメータには共通のプロパティがあり、固有のものがあるということです。例：ボタンは制御パラメータの型がboolであり、ドロップダウンリストは "menu "型である。つまり、ボタンでは1/0を切り替え、リストでは限定された選択肢を提供します。例えばスライダーは、パラメータのタイプが "range"、つまり範囲です。他にもいくつかの種類があり、どれもユニークな特性を持っています。
したがって、ベースパラメータクラスの下位に位置するクラスも同様であるべきです。CBool", "CRange", "CMenu "のようなものです。
待ってください。今度は少し抽象的な見方をしてみましょう。
Peterさんから見て、ボタン、テキストラベル、入力ボックス、ピクチャーボックスなどのコントロールに共通するものは何ですか？
待ってください。今度は少し抽象的な見方をしてみましょう。
Peterさんから見て、ボタン、テキストラベル、入力ボックス、ピクチャーボックスなどのコントロールの共通点は何でしょうか？
1.座標、寸法
2.座標依存性、寸法依存性。
3. コントロール機能のプロパティの総数によって、さらに多くのものがあります。私のカーネルには270のプロパティがあります。そのほとんどが共通です。でも、開発した機能で、多くの機能をサポートしているんです。それゆえ、このようなプロパティの数々。まずは最も単純な特性から始めなければならない。
1.コーディネートしています。
2.依存関係を調整する。
3. コントロール機能のプロパティの総数に応じて、他の多くのもの。私のコアの物件は270件です。そのほとんどが共通です。 でも、多くの機能をサポートする高度な機能があるんです。それゆえ、このようなプロパティの数々。まずは最も単純な特性から始めなければならない。
はい、もちろん最もシンプルなプロパティで。同じテキストラベルでも、どのようなプリミティブなオブジェクトで構成されるのでしょうか？あるいは、シンプルなボタンはどんな原始的なもので構成されるのだろうか？