記事"MQLプログラムのグラフィカルインターフェイスのマークアップツールとしてのMQL 第２部"についてのディスカッション
というのも、著者が読者のことを考えていないことはすでに明らかだからだ。彼は自分自身に話しかけているのであり、 標準ライブラリ（そのクラス、メソッド、変数）に完全に精通している人には理解できるだろう。著者は、自分が知っているコードを "疾走 "し、何かを修正する......。
そして、この図書館を完璧に知っている者なら、ほとんど追加は必要ないだろう。
そして、このライブラリーに完全に精通している人が、追加を必要とすることはまずないだろう。
記事の結論を注意深く読めば、著者の（論争を呼ぶ）結論が理解できるだろう：
//------------------------------------------------------------------------------------------------------------------------
1. 著者は「MQLプログラムのグラフィカル・インターフェースのレイアウトをMQL言語自体に記述するというコンセプトの実現可能性」を確認したと主張している(c)。
- 資料提示の仕様上、この結論に対して賛否は言えない。明らかではない。
//------------------------------------------------------------------------------------------------------------------------
2."キャッシュに一元的に保存された要素の動的生成を使用することで、コンポーネントの階層の作成と管理を簡素化することができます。統一されたスタイルの変更、イベント処理、レイアウトのその場での編集、後で使用するのに適した形式での保存など、インターフェース設計に関連するほとんどのタスクは、キャッシュに基づいて実装することができます。"(c)
- この結論がどのような理論的根拠に基づいて出されたのかは、技術に関する記述がないため不明であり、読者は同意も否定もできない。 読者は、この技術を紹介され、その上で、実現可能性の証明に同意するはずである。
//------------------------------------------------------------------------------------------------------------------------
3."これらの機能をまとめてみると、シンプルなビジュアル・フォーム・エディターには、ほぼすべての機能が利用可能であることがわかる。多くの "コントロール "に共通する最も重要なプロパティだけをサポートすることもできるが、それでもインターフェイスの空白を形成することができるだろう。"(c)
- 繰り返しになるが、-技術的なニュアンスの一般化された記述がなければ、グラフ・ライブラリからビジュアル・エディタを制作するシステムに精通していない読者は、著者に同意することも反論することもできない。自明ではない。
//------------------------------------------------------------------------------------------------------------------------
4."しかし、新しいコンセプトを評価する初期段階ですら、多くの労力を要したことがわかる。したがって、本格的なエディタを実際に実装するのは、かなり困難なことである。そして、それはまた別の話である。"(c)
- 私の意見では、これが最も客観的な結論である。私はこの結論に賛成です。 慌てて」作ればいいというものでもないでしょう(私自身、数年前から試行錯誤し ています)。
//------------------------------------------------------------------------------------------------------------------------
私の結論：記事の結論（すなわち最後の結論）において、著者は最も現実に近い。しかし、この記事は、トピックの展開とともに同じ結論に達するべき読者を対象としており、そのためには技術を徐々に明らかにする必要がある。この2つの記事の主な欠点は、技術の開示がないことである。その内容は、著者の自明でない解決策の実装に関する議論であり、それに対する前置きは一切ない。筆者にはこの点を考慮してもらいたい。
- www.mql5.com
記事の結論を注意深く読めば、著者の（論争的な）結論が理解できるだろう：
//------------------------------------------------------------------------------------------------------------------------
1. 著者は「MQLプログラムのグラフィカル・インターフェースのレイアウトをMQL言語自体に記述するというコンセプトの実現可能性」を確認したと主張している(c)。
- 資料提示の仕様上、この結論に対して賛否は言えない。明らかではない。
//------------------------------------------------------------------------------------------------------------------------
2."キャッシュに一元的に保存された動的な要素生成を使用することで、コンポーネントの 階層の作成と管理が容易になります。インターフェイス設計に関連するほとんどのタスクは、一様なスタイル変更、イベント処理、オンザフライでのレイアウト編集、後で使用するのに適した形式での保存など、キャッシュに基づいて実装することができます。"(c)
- どのような理論的根拠に基づいてこの結論に達したのかは、技術に関する記述がないため不明であり、読者は同意も否定もできない。 読者はこの技術を紹介され、その上で実現可能性の証明に同意するはずで ある。
//------------------------------------------------------------------------------------------------------------------------
3."これらの機能をまとめてみると、シンプルなビジュアル・フォーム・エディターには、ほぼすべての機能が利用可能であることがわかる。多くの "コントロール "に共通する最も重要なプロパティだけをサポートしても、インターフェースの空白を形成することができる。"(c)
- 繰り返しになるが、-技術的なニュアンスの一般化された説明がなければ、グラフ・ライブラリからビジュアル・エディタを生成するシステムに精通していない読者は、著者に同意することも反論することもできない。自明ではない。
//------------------------------------------------------------------------------------------------------------------------
4."しかし、新しいコンセプトを評価する初期段階ですら、多くの労力を要したことがわかる。したがって、本格的なエディタを実際に実装するのは、かなり困難なことである。そして、それはまた別の話である。"(c)
- 私の意見では、これが最も客観的な結論である。つまり、「本格的なエディタを実装するのはまた別の話だ」ということです。 私はこの結論に賛成です。ただ "軽率に "作ることはできない（私自身、数年間それを試みた）。
//------------------------------------------------------------------------------------------------------------------------
私の結論：記事の結論（すなわち最後の結論）において、著者は最も現実に近い。しかし、この記事は、トピックの展開とともに同じ結論に達するべき読者を対象としており、そのためには技術を徐々に明らかにする必要がある。この2つの記事の主な欠点は、技術の開示がないことである。その内容は、著者の自明でない解決策の実装に関する議論であり、それに対する前置きは一切ない。筆者にはこの点を考慮してもらいたい。
禁止事項なので、私は棄権する。
記事の内容を徹底的に分析した結果、私が探していた技術の「粒子」はあるのだが、それが資料の中に恣意的に散りばめられていることに気づいた。つまり、著者は理論と実装を分けて考えず、すべてをごちゃ混ぜにし、その過程で豊富なコード例で分けているのだ。私は彼のコンセプトの基本を一箇所に集め、その全体像を把握することにした。
技術を説明する記事の断片のコピー（順序はそのまま、コードサンプルは省略）：
//--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1. 標準的な要素のライブラリの一般的な構造は、「ラバースタンプ」とサードパーティ製コンテナをサポートする適合バージョンを考慮して、クラス図に示されています。(私の補足：図は与えられている）。
2.エレメントの生成とキャッシュ
これまでのところ、要素はウィンドウ・オブジェクト内の自動インスタンスとして構築されてきました。それらは基本的に「空白」であり、Createのようなメソッドによって初期化されます。GUIエレメント・レイアウト・システムは、ウィンドウからエレメントを取得するのではなく、エレメント自体を生成することができます。そのためには、何らかのストレージがあれば十分です。これをLayoutCacheと呼ぶことにしよう。基本的に、これは基本クラス（すべての要素に共通）のポインタの配列で、saveメソッドを使って配置することができます。このインターフェイスはまた、（この抽象レベルで可能であれば）要素を番号、名前、参照、または「親」関係（入れ子になった要素からコンテナへのフィードバック）の事実によって検索するメソッドを実装するか、（後でオーバーライドするために）宣言します。
LayoutBaseクラスに静的メンバとしてキャッシュを追加しましょう。各ウィンドウは、それ自身のためにキャッシュ・インスタンスを作成し、CreateLayoutのようなメソッドの一番最初にsetCacheを使用してそれを作業キャッシュとして設定する必要があります。MQLプログラムはシングルスレッドなので、（複数のウィンドウが必要な場合）ウィンドウが並列に形成され、キャッシャー・ポインターを奪い合うことはありません。スタックが終了すると、LayoutBaseのデストラクタで自動的にポインタをクリアします。これは、レイアウト記述の最後の外部コンテナを残したことを意味し、それ以外のものを保存する必要はありません。参照をゼロにするということは、キャッシュをクリアするということではありません。ただ、次のレイアウトの可能性があるときに、間違って別のウィンドウから "コントローラ "を追加しないようにするためです。キャッシュを埋めるために、LayoutBaseに新しい種類のinitメソッドを追加してみましょう。今回は、パラメータに「サードパーティ」のGUI要素へのポインタや参照を入れません。テンプレートのおかげで、新しいTを記述し、レイアウト処理中にオブジェクトを生成することができます（デフォルトでは、一度に1つのオブジェクトですが、オプションで複数持つこともできます）。
具体的なキャッシュの実装は、標準ライブラリの 要素であるStdLayoutCacheのために書かれています（ここでは略語で説明し、完全なコードは付録にあります）。
getメソッドは、シーケンス番号（入力パラメータが正の場合）または識別子（マイナス記号で渡される）のどちらかで「コントロール」を検索することに注意してください。ここで識別子とは、イベント・ディスパッチ用の標準コンポーネントのライブラリによって割り当てられた一意の番号を意味する。イベントでは lparam パラメータで渡されます。
3.スタイライザー
キャッシュは要素を一元的に処理するオブジェクトであるため、スタイリング以外の多くのタスクを実行するために使用すると便利です。特に、一つのスタイル（色、フォント、インデント）のルールを統一的に要素に適用することができます。各「コントロール」に対して別々に同じプロパティを記述する代わりに、このスタイルを一箇所で設定するだけで十分です。さらに、キャッシュされた要素に対するメッセージを処理するタスクを、キャッシュが引き受けることができます。潜在的には、すべての要素を動的に構成し、キャッシュし、インタラクティブに操作することができる。そうなれば、ウィンドウ内で「明示的な」要素を宣言する必要はまったくなくなる。もう少し後で、動的に作成された要素が自動的な要素と比較してどのように有利なのかを見ることになる。
一元化されたスタイルをサポートするために、StdLayoutCacheクラスにはストール・メソッドがあります。applyメソッドは、各「コントロール」に対して、初期化段階（STYLE_PHASE_BEFORE_INIT）とコンテナへの登録段階（STYLE_PHASE_AFTER_INIT）の2回呼び出されます。したがって、LayoutBase::initメソッドは最初のフェーズへの呼び出しを追加し、デストラクタは同様の文字列を追加しますが、2番目のフェーズにはSTYLE_PHASE_AFTER_INITを追加します。
2つのフェーズが必要なのは、スタイリングの目的が異なるからです。いくつかの要素は、スタイライザーで設定された一般的なプロパティよりも高い優先順位を持つ個々のプロパティを持つ必要があることがあります。初期化段階では、"コントロール "はまだ空の状態です - レイアウトで行われた設定はありません。登録段階では、すべてのプロパティがすでに設定されており、さらにそれに基づいてスタイルを変更することができます。最もわかりやすい例は次のようなものです。read-only」フラグを持つすべての入力フィールドを灰色で表示することが望ましい。しかし、"read-only "プロパティは、初期化後のレイアウト処理中に "control "に割り当てられるので、最初の段階は適さず、2番目の段階が必要となる。一方、通常、すべての入力フィールドがこのフラグを持つわけではなく、他のすべてのケースでは、レイアウト言語が選択的なカスタマイズを行う前に、デフォルトの色を設定する必要があります。
ちなみに、MQLプログラムのインターフェイスを異なる国の言語に一元的にローカライズする場合にも、同様の技術を使用することができる。
4.イベント処理
論理的にキャッシュに割り当てられる2つ目の機能は、イベントの処理です。LayoutCacheクラスでは、これらのためにスタブ・メソッドが追加されています（Cはクラス・テンプレートのパラメータです）：ここでも、派生クラスで実装することができますが、必ずしもそうする必要はありません。イベント・コードは特定のライブラリによって定義されます。
このメソッドを動作させるには、標準ライブラリと同様のイベント・キャプチャ・マクロ定義をマップに記述する必要があります。
5.例 2.コントロールとの対話
デモ・プロジェクトには、CControlsDialogクラスがあり、標準ライブラリの「コントロール」の基本的な型が含まれています。最初の例から類推して、コントロールの作成メソッドをすべて削除し、CreateLayoutひとつに置き換えてみましょう。ちなみに、古いプロジェクトにはこれらのメソッドが17個あり、複雑な条件演算子の助けを借りて互いに呼び出していた。キャッシュ・クラスでは、onEventイベント・ハンドラが宣言されている。このハンドラはメッセージを親ウィンドウに反映し、以前のバージョンの例のように情報フィールドに表示されます。
スタイラークラスは、すべての要素に同じフィールドを設定すること、すべてのボタンに標準以外のフォントを設定すること、「読み取り専用」属性を持つCEditを灰色で表示することを提供します（私たちは1つ持っていますが、追加された場合、それは自動的に一般的な設定に該当します）。
入れ子になった要素をコンテナのサイズに合わせて拡大縮小するアルゴリズムが CBox クラスに追加されました。これはAdjustFlexControlsメソッドで実行され、コンテナの整列フラグに特別な値WND_ALIGN_CONTENTが指定されている場合にのみ有効になります。これは標準の ENUM_WND_ALIGN_FLAGS 列挙の一部ではない。コンテナは、"コントロール "を分析して、どれが固定サイズでどれが固定サイズでないかを確認する。サイズが固定されている "コントロール "とは、コンテナの側面への整列が（特定の次元で）指定されていないものである。そのような "コントロール "すべてについて、コンテナはそれらのサイズの合計を計算し、それをコンテナの合計サイズから引いて、残りの "コントロール "すべてに比例して残りを分割する。例えば、コンテナ内に2つの「コントロール」があり、そのどちらもアンカーを持っていない場合、コンテナ全体の領域を半分に分け合うことになる。
これは非常に便利なモードですが、入れ子になったコンテナのセットで使用すべきではありません。サイズ計算のアルゴリズムがワンパスであるため、コンテナの領域に対する内部要素のアライメントが不確定になり、コンテンツに合わせて調整されます（このため、レイアウトクラスには特別なON_LAYOUT_REFRESHイベントがあり、ウィンドウはサイズ計算を繰り返すために自分自身に送信できます）。
ON_EVENT_LAYOUT_CTRL_DLGマクロは、NotifiableButtonクラスの任意のボタン（ここでは1つだけ）のマウスクリック通知を有効にします。ON_EVENT_LAYOUT_INDEXマクロは、キャッシュ内の指定されたインデックスのボタンに同じイベントを送ります。しかし、ON_EVENT_LAYOUT_ARRAYマクロの最後の行は、そのlparam識別子が一致すれば、キャッシュ内の任意の要素にマウス・クリックを送るので、このマクロは書けませんでした。
原理的には、すべての項目をキャッシュに移動し、それらのイベントを新しい方法で処理することもできますが、古い方法も機能しますし、それらを組み合わせることもできます。
例 3.DynamicForm ダイナミックレイアウト
この最後の例では、すべての要素がキャッシュ内で動的に作成されるフォームを見ていきます。これにより、いくつかの重要な新機能が得られます。
前の例と同様に、キャッシュは要素のスタイリングをサポートします。スタイリングの設定は、同じように目立つボックスだけで、これにより、コンテナが互いに入れ子になっているのが見え、マウスで好きなように選択できるようになります。
CreateLayoutメソッドの内部では、次のような単純なインタフェース構造が記述される。メイン・コンテナは、いつものようにウィンドウのクライアント領域全体を占める。上部には、InjectとExportの2つのボタンがあるブロックがある。その下のスペースはすべて、左右の列に分かれたコンテナで占められている。
新しい要素が挿入されるべきコンテナは、まず "column1 "という名前でキャッシュから検索されます。このコンテナは、injectionPanelオブジェクトが生成されるときに、最初のパラメータとして渡されます。渡される要素がすでにキャッシュ内にあることは、レイアウトアルゴリズムにおいて特別な方法で考慮されます。このようにして、「古い」コンテナに要素を追加することができる。
ユーザーの選択に基づいて、getPtr補助メソッドのnew演算子を使って必要な型のオブジェクトが作成される。追加された "コントロール "が正しく動作するために、一意の識別子がランダムに生成される。特別なAutoPtrクラスは、コードブロックを離れるときのポインタの削除を提供します。
要素を追加しすぎると、それらはコンテナの境界の外に出てしまう。これは、コンテナ・クラスがオーバーフローに正しく対応する方法をまだ知らないために起こる。この場合、たとえばスクロールバーを表示して、境界からはみ出した要素を非表示にすることができる。
しかし、それは問題ではない。この例のポイントは、フォームをカスタマイズすることで動的なコンテンツを生成し、必要な充填とコンテナのサイズを提供できるということです。
要素を追加するだけでなく、このダイアログボックスは要素の削除方法も知っています。フォーム上のどの要素もマウス・クリックで選択できます。要素のクラスと名前はログに表示され、要素自体は赤枠で強調表示されます。すでに選択されている要素をクリックすると、ダイアログボックスが削除の確認を促し、同意すれば要素が削除されます。これらはすべてキャッシュクラスに実装されています。
インジェクト・ボタンによって追加されたものだけでなく、キャッシュで利用可能なすべてのUI要素を削除することができます。例えば、左半分や右の "ラジオボックス "全体を削除することができる。しかし、一番面白いのは、2つのボタンがある一番上のコンテナを削除しようとした場合だ。その結果、「エクスポート」ボタンはダイアログ・ボックスとの結合を失い、チャート上に残ることになります。
これは、このボタンだけが意図的に動的変数ではなく自動変数として記述された要素だからです（フォームクラスにはCButton m_button3のインスタンスがあります）。
標準ライブラリがインターフェイス要素を削除しようとすると、これをCArrayObj配列クラスに委譲し、CArrayObj配列クラスはポインタ型をチェックし、POINTER_DYNAMICを持つオブジェクトだけを削除します。このように、要素が互いに入れ替わったり、完全に削除されたりするような適応的なインターフェースを構築するには、動的配置を使用することが望ましく、キャッシュはそのための用意された解決策を提供する。
最後に、ダイアログの2番目のボタン「エクスポート」に目を向けてみましょう。その名前から推測できるように、これはダイアログの現在の状態をMQLレイアウト構文でテキストファイルとして保存するためのものです。もちろん、フォームの外観をカスタマイズできるのは、デモンストレーションを目的とした限られた範囲に限られますが、外観を既製のMQLコードにアンロードできる可能性があり、それをプログラムにコピーして同じインターフェースを得ることは、潜在的に非常に価値のある技術です。もちろん、転送されるのはインターフェイスのみで、イベント処理コードやスタイライザーの一般的な設定は独立してプラグインする必要があります。
エクスポートは LayoutExporter クラスによって提供されます。
- www.mql5.com
私は上記の文章からシステム、コンセプト、テクノロジーを見つけようとしたが、見つからなかった。スケッチ」ですらなく、意識の流れに近い。しかし、常にコード例に切り替えていれば、それに気づくことはないだろう。残念なことだ。
実際、OOPを知っている人にとっては、そこですべてが明らかになる。
知らない人が悪いのだ。
OOPを知っている人間にとっては、かなり明確なことだ。
知らない人が悪い。
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
新しい記事 MQLプログラムのグラフィカルインターフェイスのマークアップツールとしてのMQL 第２部 はパブリッシュされました:
本論文では、MQLプログラムのウィンドウインタフェースを記述するための新しい概念をMQLの構造体を用いて確認します。 MQLマークアップに基づいてGUIを自動的に作成することで、要素をキャッシュして動的に生成したり、イベントを処理するためのスタイルや新しいスキームを制御したりする関数が追加されます。 標準のコントロールライブラリの強化版が添付されています。
キャッシュで利用可能なインターフェース要素はすべて削除することができます。 このようにして、例えば左半分全体を削除したり、右の "radiobox "を削除したりすることができます。最も興味深いのは、2つのボタンで上部のコンテナを削除しようとすると、何が起こるかということです。 これより、エクスポートボタンはダイアログに拘束されず、チャート内に留まります。
編集可能なフォーム：要素の追加と削除
動的変数ではなく、意図的に自動変数として記述されている唯一の要素であるために起こります（フォームクラスでは、CButtonのインスタンスm_button3があります）。
標準ライブラリがインターフェースの要素を削除しようとするとき、を配列クラスCArrayObjに委譲し、配列クラスはポインタの型をチェックし、POINTER_DYNAMICを持つオブジェクトのみを削除します。 このように、要素が互いに入れ替わったり、完全に削除されたりするような適応的なインタフェースを構築するためには、動的配置を使用することが望ましいことが明らかになり、キャッシュはこれに対する解決策を提供しています。
作者: Stanislav Korotky