Все объекты, используемые в техническом анализе, имеют привязку на графиках по координатам цены и времени – трендовая линия, каналы, инструменты Фибоначчи и т.д. Но есть ряд вспомогательных объектов, предназначенных для улучшения интерфейса, которые имеют привязку к видимой всегда части графика (основное окно графика или подокна индикаторов...
Переменные должны быть объявлены перед их использованием. Для идентификации переменных используются уникальные имена. Описания переменных используются для их определения и объявления типов. Описание не является оператором. Индексом массива может быть только целое число. Допускаются не более чем четырехмерные массивы. Нумерация элементов...
Любая программа оперирует данными. Данные могут быть различных типов в зависимости от назначения. Например, для доступа к элементам массива используются данные целочисленного типа. Ценовые данные имеют тип двойной точности с плавающей точкой. Это связано с тем, что в языке MQL5 не предусмотрено специального типа для ценовых данных. Данные...
ダイアログの要素（フォーム、コントロール（ボタン、リスト、画像））には、いくつかのプロパティがあります。手続き型プログラミングでは、「プロパティ」「フィールド」という概念は定義されていません。手続き型プログラミングでは、関数と変数（グローバルまたはローカル）があります。しかし、変数は共通なので、個々のコントロールの特性を記述するのには使えない。では、その解決策は？シンプルに言えば、構造です。
はい、構造体は、コントロールの必要なプロパティの記述と、ネストされた（最大で無限）コントロールの配列を持つことができます。
これらのものはすべて、ダイアログボックスの配列に格納されています。
より普遍的なものにすることができる。制御記述構造は、プロパティ配列とスレーブ要素配列の2つの配列で構成される。プロパティ配列は、プロパティと値のペアの構造体の配列である。この方法では、新しいコントロールはそれぞれ任意のプロパティセットを 持つことができる。しかし、これでは加工に不便です。寸法、位置、色、フレームなど、コントロールに必要なすべてのプロパティを構造で指定する方が論理的であろう。
また、この構造体は、コントロールのピクセルの配列を含むことになります。
マウスイベントを受信すると、すべての配列がループして、カーソルが特定のコントロールに当たっているかどうかをチェックします。チェックは、最後のコントロールから最初のコントロールまで行われます。
どのコントロールにカーソルがあるかを判断した後、与えられた配列要素を repaint 関数に送り、リソース配列を更新してチャート上の画像を更新します。
GUI関連で何を投稿し、何をしたかは知りませんが、私のスレッドでは、技術的な提案も、解決策も、議論も一切していません。サードパーティのソリューションを指摘し、車輪の再発明をしないよう促す、空虚な荒らし行為のみ。
話を元に戻します。
私が標準ライブラリに精通している限り（実際にはほとんどないのですが）、エレメントとウィンドウはMTオブジェクトで構成されています。つまり、私たちの文脈では、彼らはキャンバスに描かれていないのです。もちろん描画はされますが、キャンバス上には描画されないので、ピクセルの色を制御したり、表面のグラデーションを作成したりすることはできません。
理論的には、ライブラリの構造をコピーして、キャンバス上にアナログを作ることができます。理論的には...
問題は、CCanvas自体がその上でGUIを作るのに適していないことです。なぜ？なぜなら、kanvasシステムは主にグラフィックプリミティブに使用されるからです。つまり、要するにこのクラスはプリミティブ以外何も提供しないのです。GUIアーキタイプは自分で作る必要があります。そしてこの場合、授業は必要ない。自前のソリューションでやりくりする方が便利です。結局、クラスがなくても長方形のマーカーを描くことはできるのです。キャンバスを作成したり、読み込んだりするのと同じです。それはとてもシンプルなことです。そのため、私は自分なりの解決策を優先しました。
しかし、CCanvasなしではやっていけない人がいます。だから、こだわらないんです。
CCanvasの問題点は、そのGUIがチャートウィンドウに厳密に縛られていることです。
つまり、ターミナル・インターフェイス・モジュールとして本格的なウィンドウを作ることはできないのです。
また、独自のインターフェースモジュールを書くことができれば、非常にクールです。
無論）
Tcl DLL (Tool Common Languageの略)に、Python/Ruby/その他でGUIとして共有されるTkグラフィックスを搭載したインタフェースを投稿しました
目標はGUIを手に入れることではなく、素敵な副産物を手に入れることでした :-)
tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ;
便利で、何より短いというのが私の意見です :-)
私は誰も煽っていません - 私はtcl/tkを知っていて、それを使っていて、私の経験を共有しています（sourceforge atclを参照）。
はい、マックス、それこそTCLと、その時議論していたあなたのプロトタイプのことです。その際、ユーザーが自分のコンピュータに適切なライブラリをインストールする必要があるという制約があった。難しいとは思いませんでしたが、やはり一定の制約がありますね。
それは過去に置いておきましょう。マックス、議論に加わってくれ。ローマンも参加してね )))。
以上のことから、structure要素は特定のダイアログコントロールであり、それ自身のプロパティを含み、ネストしたコントロールを含むことができることが理解できる。このようなユニバーサル・コントロールの特性は、開発者の想像力によってのみ制限される。
もちろん、この構造を避けて、コントロールのプロパティを多次元配列 で記述することもできるが、コントロールのどのインデックスにどのプロパティが格納されているかを明確に覚えておく必要があるため、初期の費用対効果は良くない。また、配列に異種データを含めることはできません。手続き型プログラミングにおける制御要素の記述は、構造体を通じてのみ可能であることが判明した。すなわち、構造体要素は、具体的なコントロール、すなわち、ダイアログの具体的なオブジェクトとそのプロパティである。
CCanvasの問題点は、そのGUIがチャートウィンドウに厳密に縛られていることです。
つまり、ターミナル・インターフェイス・モジュールとして本格的なウィンドウを作ることはできないのです。
また、独自のインターフェースモジュールを書くことができれば、非常にクールです。
そして、その逆、つまりインターフェースとチャートをリンクさせることもあるでしょう。例えば、時間や価格と厳密に連動したボタンを作る。
テーブル、タブ、メニュー、ホイッスルをすべて備えた独立したGUIをすぐに作成することができます。C#でも、BASICでも。そして、チャートの内側は、外部アプリケーションにとって大きな問題です。
ダイアログの要素（フォーム、コントロール（ボタン、リスト、画像））には、いくつかのプロパティがあります。手続き型プログラミングでは、「プロパティ」「フィールド」という概念は定義されていません。手続き型プログラミングでは、関数と変数（グローバルまたはローカル）があります。しかし、変数は共通なので、個々のコントロールの特性を記述するのには使えない。では、その解決策は？シンプルに言えば、構造です。
はい、構造体は、コントロールの必要なプロパティの記述と、ネストされた（最大で無限）コントロールの配列を持つことができます。
これらのものはすべて、ダイアログボックスの配列に格納されています。
より普遍的なものにすることができる。制御記述構造は、プロパティ配列とスレーブ要素配列の2つの配列で構成される。プロパティ配列は、プロパティと値のペアの構造体の配列である。この方法では、新しいコントロールはそれぞれ任意のプロパティセットを 持つことができる。しかし、これでは加工に不便です。寸法、位置、色、フレームなど、コントロールに必要なすべてのプロパティを構造で指定する方が論理的であろう。
また、この構造体は、コントロールのピクセルの配列を含むことになります。
マウスイベントを受信すると、すべての配列がループして、カーソルが特定のコントロールに当たっているかどうかをチェックします。チェックは、最後のコントロールから最初のコントロールまで行われます。
どのコントロールにカーソルがあるかを判断すると、その配列の要素が repaint 関数に送られ、リソース配列が更新され、チャート上の画像が更新されます。
1.ウィンドウ、ボタン、チェックボックスといった基本的なコントロールのシンプルな構造を設計したとします。それぞれは構成要素であるオブジェクトの集合で構成されています。チェックボックス - ベース、テキスト、アイコンです。ボタン - ベース、テキスト、アイコンなど。各要素の各オブジェクトは、それぞれ独自のプロパティセットを持つ必要があります。構成やクラスで書くこともできますが、私見ですが、不便です。なぜ？- なぜなら、ウィンドウに配置する場合、キャンバス上でカーソルを使って探す必要があるからです。カーソルを動かすと、ピントが合うようにしなければならないのです。そのためには、それらの現在座標が配列になっている必要があります。また、それらのプロパティ（現在の座標を含む）がすべて同じ配列になっていればより便利です。このようにして、カーソルがフォーカスしているキャンバス上の任意の要素のプロパティに即座にアクセスすることができます。また、項目の配列でループするのも簡単です。
つまり、カーソルがヒットした要素を見つけるために、ループでONE配列をたどる方が簡単なのです。この配列がグローバルであれば、さらに便利である。そして、任意の関数で、そこから必要な情報を取り出し、必要な特性、必要な要素の値を変更することができるのです。
これは、素子へのアクセスを最短にし、その処理を最速にするものです。これが私の "芯 "です。
2.しかし、標準的なOOPを最大限模倣しようとするプロの気質を知っているので、私はこの技術を提案しない。
3. 画素の配列は、どこにも保存する必要がない。配列に含まれる要素のパラメータに従って、必要な瞬間に構築される。例：ウィンドウを再描画する必要がある場合。repaint関数を呼び出す。この関数は，要素の配列を呼び出し，そのすべてのプロパティを確認し，ピクセルの配列を宣言し，そのサイズを計算し，ループ内でそのオブジェクトを順次描画し，ResourceCreate()を呼び出すものです．それだけです。
カーソルの下に捕まった要素は、同じ関数に送られて再描画される。通知（再描画フラグ）とアイテム配列の番号を受け取ります。次に、ResourceReadImage() により必要なリソースを呼び出してピクセル配列に格納し、ピクセル配列の内部で必要な要素の領域を求めてそのすべてのオブジェクトを再描画します。 それだけです。
1.ウィンドウ、ボタン、チェックボックスといった基本的なコントロールのシンプルな構造を設計したとします。それぞれは構成要素であるオブジェクトの集合で構成されています。チェックボックス - ベース、テキスト、アイコンです。ボタン - ベース、テキスト、アイコンなど。各要素の各オブジェクトは、それぞれ独自のプロパティセットを持つ必要があります。構成やクラスで書くこともできますが、私見ですが、不便です。なぜ？ - なぜなら、ウィンドウに配置する場合、キャンバス上でカーソルを使って探す必要があるからです。カーソルを 動かすとフォーカスが合うようにするには、現在の座標を配列にしておく必要があります。また、それらのプロパティ（現在の座標を含む）がすべて同じ配列になっていればより便利です。このようにして、カーソルがフォーカスしているキャンバス上の任意の要素のプロパティに即座にアクセスすることができます。また、項目の配列でループするのも簡単です。
つまり、カーソルがヒットした要素を見つけるために、ループでONE配列をたどる方が簡単なのです。この配列がグローバルであれば、さらに便利である。そして、任意の関数で、そこから必要な情報を取り出し、必要な特性、必要な要素の値を変更することができるのです。
これは、素子へのアクセスを最短にし、その処理を最速にするものです。これが私の "芯 "です。
2.しかし、標準的なOOPを最大限模倣しようとするプロの気質を知っているので、私はこの技術を提案しない。
3. 画素の配列は、どこにも保存する必要がない。配列に含まれる要素のパラメータに従って、必要な瞬間に構築される。例：ウィンドウを再描画する必要がある場合。repaint関数を呼び出す。この関数は，要素の配列を呼び出し，そのすべてのプロパティを確認し，ピクセルの配列を宣言し，そのサイズを計算し，ループ内でそのオブジェクトを順次描画し，ResourceCreate()を呼び出すものです．それだけです。
カーソルの下に捕まった要素は、同じ関数に送られて再描画される。通知（再描画フラグ）とアイテム配列の番号を受け取ります。次に、ResourceReadImage() により必要なリソースを呼び出してピクセル配列に格納し、ピクセル配列の内部で必要な要素の領域を求めてそのすべてのオブジェクトを再描画します。それだけです。
実はこれ、建設技術に関係なく使えるはずなんです。しかし、それは違う捉え方をすることもあります。あなたの場合、ループ内で配列を渡して、その時点でどのコントロールにカーソルがあるかを判断しています。このように、インデックスを定義すると、すぐに見つかった項目のプロパティが表示されます。しかし、異なる種類の データを1つの大きな配列に格納するにはどうすればよいのでしょうか？
実は、これは建設技術に関係なく起こるべきことなのです。捉え方が違うだけなのです。この場合、配列をループして、どのコントロールがその時点でカーソルを持っているかを判断します。このように、インデックスを定義すると、すぐに見つかった項目のプロパティが表示されます。しかし、異なる種類の データを1つの大きな配列に格納するにはどうすればよいのでしょうか？
原理的には、型を一般化することが可能である。オブジェクトのプロパティの大半がint型であれば、何も悪いことは起きないという結論に達しました。その他の（ダブルはグラフィカルオブジェクトのプロパティには実質的に存在しない）省略型は、簡略化のために無視した。 メモリの「オーバーラン」なんて、考える意味がないくらい些細なことです。もちろん、プロフェッショナリズムのためには、そんな冒涜的なことはできませんが)))。しかし、これは21世紀であり、私は焚き火に脅かされることはない）。
モノの名前を数字にして、一般的なモノの性質のシリーズに入れました。
唯一、別の種類のデータが必要だったのは、制御パラメータでした。このカーネルでは、パラメータのプロパティと、値そのものを文字列型に格納しており、何にでも（というか、パラメータのプロパティに規定されているものに）簡単にキャストできるようになっています。
ヒント：「制御要素パラメータ」とは、「機器が管理するパラメータ」のことです。1.ウィンドウ、ボタン、チェックボックスといった基本的なコントロールのシンプルな構造を設計したとします。それぞれは構成要素であるオブジェクトの集合で構成されています。チェックボックス - ベース、テキスト、アイコンです。ボタン - ベース、テキスト、アイコンなど。各要素の各オブジェクトは、それぞれ独自のプロパティセットを持つ必要があります。構成やクラスで書くこともできますが、私見ですが、不便です。なぜ？- なぜなら、ウィンドウに配置する場合、キャンバス上でカーソルを使って探す必要があるからです。カーソルを動かすと、ピントが合うようにしなければならないのです。そのためには、それらの現在座標が配列になっている必要があります。また、それらのプロパティ（現在の座標を含む）がすべて同じ配列になっていればより便利です。このようにして、カーソルがフォーカスしているキャンバス上の任意の要素のプロパティに即座にアクセスすることができます。また、項目の配列でループするのも簡単です。
つまり、カーソルがヒットした要素を見つけるために、ループでONE配列をたどる方が簡単なのです。この配列がグローバルであれば、さらに便利である。そして、任意の関数で、そこから必要な情報を取り出し、必要な特性、必要な要素の値を変更することができるのです。
これは、素子へのアクセスを最短にし、その処理を最速にするものです。これが私の "芯 "です。
2.しかし、標準的なOOPを最大限模倣しようとするプロの気質を知っているので、私はこの技術を提案しない。
3. 画素の配列は、どこにも保存する必要がない。配列に含まれる要素のパラメータに従って、必要な瞬間に構築される。例：ウィンドウを再描画する必要がある場合。repaint関数を呼び出す。この関数は，要素の配列を呼び出し，そのすべてのプロパティを確認し，ピクセルの配列を宣言し，そのサイズを計算し，ループ内でそのオブジェクトを順次描画し，ResourceCreate()を呼び出します．それだけです。
カーソルの下に捕捉された要素は、同じ関数に送られ再描画される。通知（再描画フラグ）とアイテム配列の番号を受け取ります。そして、ResourceReadImage()によって必要なリソースを呼び出してpixel配列に入れ、さらにpixel配列の中から必要な要素の領域を探してそのオブジェクトをすべて再描画します。それだけです。
ああ、この永遠のネガティヴはウープに、まさに一線を越えている。
どうしてそうなったのか、不思議に思ったことはないだろうか。要は、手続き型で書いていてOOPを知らない人の多くは、関数をグループ化したいという欲求に直面し、その欲求が、これらの関数を一つのメモリ領域にまとめて参照したい、つまり変数に格納されている関数を持つ領域を物理的に参照したいという欲求に発展していくのです。そして、選択した関数の束を、コードを重複させることなく変更したい（継承ができる）。そのため、最初は手続き型しか知らなかった人が、しばらくして「なぜmcl（多重継承のこと）にはこんなに制約があるのか」という疑問を持つのです。
一般的には、手続き型に慣れてしまうと後で再教育するのが大変なので（ほとんどの 人は）、OOPを一度に教える方が楽だと考えられていますが、当初は手続き型しかなかったため、他にも......。は、上記のとおりです。
ZS 一般的なOOP、手続き型コードのレベルでOOPに精通しているようなもの、そして本当にOOPをフルに使っているものなど、バリエーションは様々です。
クラスは関数のメモリ（テーブル）を参照するもので、メインの配列＋変数への参照を維持したまま書き換えや拡張が可能です。 その他は忘れました......。(32バイトのような)
サーチエターナル問題で、最近、内蔵ソート機能とレッドソート（テンプレートソートの一つ）を比較したところ、特定の条件で3～6倍の速度低下（内蔵は負けた＝）。
GUIでは、標準的な方法があると思います。
,
うっ、この永遠のOOPへのネガキャン、右往左往。
どうしてそうなったのか、不思議に思ったことはないだろうか。問題は、OOPを知らずに手続き型で書いている人の多くが、関数をグループ化したいという欲求に直面し、その欲求が、関数を一つのメモリ領域にまとめて参照したい、つまり、変数に格納された関数を持つ領域を物理的に参照したいという欲求に発展していくことである。そして、選択した関数の束を、コードを重複させることなく変更したい（継承ができる）。そのため、最初は手続き型しか知らなかった人が、しばらくして「なぜmql（多重継承のこと）にはこんなに制約があるのですか？
一般的には、手続き型に慣れてしまうと再教育が大変なので（ほとんどの人は）、OOPを一度に教える方が簡単だと言われていますが、当初は手続き型しかなかったという人もいますし......。は、上記のとおりです。
ZS 一般的なOOP、手続き型コードのレベルでOOPに精通しているようなもの、そして本当にOOPをフルに使っているものなど、バリエーションは様々です。
クラスは関数のメモリ（テーブル）を参照するもので、メインの配列＋変数への参照を維持したまま書き換えや拡張が可能です。 その他は忘れました......。(32バイトのような)
サーチエターナル問題で、最近、内蔵ソート機能とレッドソート（テンプレートの一つ）を比較したところ、特定の条件で3〜6倍のスピードロス（内蔵は負けた＝）。
GUIでは、標準的な方法があると思います。
,
私は、OOPという概念に否定的ではありません。私自身はその信奉者です。規格に否定的なところがある。正確には、無意識に従うこと）。
それはさておき、私はOOPに賛成です。でも、私は簡略化されたOOPに賛成です。