MQLで書かれたUIのギャラリー - ページ 71

[Реter Konow]

Edgar Akhmadeev #:

...私は入手可能な情報に従ってコードを書き、美しいインターフェースを手に入れた。そして、個人的に必要なものを実現できないことにぶつかった。

ところで、当時はうまくいかなかったことが、すでにうまくいっている。当時はパラメータをテーブルに出力できなかったことを覚えている。今は簡単にできる。テーブルが機能し、値を出力することができる。それはすでにエンジンに実装されています。これは単なる記録です。

[Edgar Akhmadeev]

何が必要かを知っているだけでなく、モックアップも作りました。ここにあなたの修正したコードとレイアウトhttps://www.mql5.com/ru/forum/467909/page37#comment_53863397。

私は正確に（あなたの言葉で）動的で生成されたテーブルが必要です。つまり、プログラムによって不定数の行を追加し（まあ、常識的には制限されますが）、それらを埋め、都合よくフレームではなくテーブル自体をスクロールさせます。見出しが定位置に留まるように。

これが、今のところあなたの作品にあるものだ。だから私は静かに正座して待っているんだ。私自身は急がないし、あなたにとっても急がない。私は永遠に生きるつもりだ。今のところうまくいっている。

[Реter Konow]

Edgar Akhmadeev #:

何が必要かを知っているだけでなく、モックアップも作りました。修正したコードとレイアウトはこちらhttps://www.mql5.com/ru/forum/467909/page37#comment_53863397

私は正確に（あなたの言葉で）動的で生成されたテーブルが必要です。つまり、プログラムによって不定数の行を追加し（まあ、常識によって制限される）、それらを満たし、便利なことに、それを持つフレームではなく、テーブル自体をスクロールします。見出しを所定の位置に保つ。

これが、今のところあなたの作品にあるものだ。だから、私は静かに正座して待っているんだ。私自身は急がないし、あなたにとっても急がない。私は永遠に生きるつもりだ。今のところうまくいっている。

なるほど。 ダイナミック・テーブルとジェネレーテッド・テーブルは、僕と君にとって必要なものだから、そうなるだろうね。新年までにはすべての仕事を終わらせるつもりだ。

[hini]

進捗状況は？

[Реter Konow]

hini #:
我々はどこまで進歩したのだろうか？

今日、動的で生成された表という概念が形成されつつあり、それは科学的なグラフと一体となって機能することになっている。課題は、表とグラフという技術的な部分を発展させるだけでなく、分析作業におけるこれらのツールの「共生」の方法を見つけることである。

以下はその一例である：

1.データはファイルにアップロードされる。特別なアルゴリズムが、データを表、行、列に分割する。

2.ユーザーは必要な表にアクセスし、行を選択してダブルクリックし、その行または列の図形を使って曲線または図を描く。

3.ユーザーはテーブルの必要なセルを選択し、その中にあるパラメータに関連するデータによって新しいテーブルの構築を呼び出す。

4.ユーザーは、表からグラフへ、グラフから表や円グラフへ、"オン・ザ・フライ "で新しい表やグラフを組み立てたり生成したりする。簡単なクリックとウィンドウへのパラメータ入力により、表示されるグラフの中で、さまざまな「角度」から、さまざまな組み合わせでデータを見ることができる。

これらすべてが、生産的な作業とデータの関係やパターンの探索に貢献することは間違いない。

私は、表、グラフ、チャートを通してデータをダイナミックに扱う便利なシステムを導入するつもりだ。

最も重要なのは、正しいコンセプトである。それを形にするのに一番時間がかかる。技術的な実装には比較的時間がかからない。

追伸：また、GUIビルダーとマークアップ言語についての最初の記事を準備中です。

P.S.S. 記事が公開される頃には、コードベース用のバージョンも用意し、希望者はコンストラクタをダウンロードできるようにするつもりだ。

一般的には、多くの仕事があります）。

[Реter Konow]

私の計画を説明しよう。

1.マークアップ言語の教科書を作る。

マークアップ言語の完全な教科書を集める必要がある。

2.インターフェイスビルダーとKIB言語の記事を書く。

完成した学習教材を一連の記事に分割し、コード、図、写真、GIFを追加する。

3.最初の記事を公開する前に、KIB のコードテンプレートを公開することだけを目的とした専用のスレッドを開く。希望者は、既成のパーツを借りて簡単にGUI を 作ることができる。また、希望者は KIB コードを追加できるようにする。

4.最初の記事が公開される前に、ビルダーの最新版をコードベースに投稿する。

そのページでは、写真、GIF、動画を含む詳細な説明書を公開する。

5.記事の冒頭にビルダーへのリンクとインストール手順を示し、記事の最後にテンプレートのあるブランチへのリンクを残す。このように、記事を読んだ直後から、読者は既製のウィンドウやエレメントのグループを借りて、グラフィカル・インターフェースを作ってみることができる。そして、学びながら実験し、インターフェイスを改良していくのである。

6.私の考えでは、読者にデザイナーの能力を簡単に理解してもらい、素早くマスターしてもらうためには、資料の提示を単純化し、有益な写真、読みやすい図式、コメント付きのコードを豊富に記事にする必要がある。だからこそ、私は「シンプルであればあるほど良い」をモットーに、論理的なシンプルさと意味の明確さを追求して記事を書いていく。

7.コンストラクタをコードベースに公開する前に、いくつかの下準備をする必要がある：

a) カテゴリー名を英語に翻訳する。

b) コンストラクタのコンパイル時に表示される警告を完全に削除する（KIBコードではない）。

c) コントロールの動作について、以前から指摘されていたバグを修正。

d) エンジンに接続されたユーザーコードをデバッグするための「スタブ」を置く。

このアイディアによると、デバッグ中にエンジンの行をコメントするだけでエンジンがオフになり、"UIDATA.mqh "サービスファイルからのグラフィカルコアとラッパー関数だけが接続されたままになります。コンストラクタの他のすべての正規関数は、特別なファイルで「ストッパー」として機能する「空の関数」として設定されます。このファイルの行は、デバッグの前にユーザーによってアンコメントされる。

これがコンセプトだが、実際にはまだチェックしていない。

8.というのも、コンストラクターとマークアップ言語全体を簡単に説明し、その目的、機能、装置について読者に完全に理解してもらう必要があるからだ。また、今後の記事の内容をリストアップし、今後の教材配布の明確なスキームを加えるつもりだ。

私の考えでは、記事はレッスンであり、したがって教材のプレゼンテーションは教育的であるべきである。

P.S.当初、私はアナトリー・コジャルスキーによるグラフィカル・インターフェースに関する有名な記事「簡単で速いライブラリ」の例に頼ることにした。私にとっては、このトピックを明らかにする最も完全な結果である。同時に、Anatolyの記事の前後にUIライブラリを作成するために価値ある試みをした他の才能ある著者の貢献にも敬意を表したい。特にドミトリー・フェドセーエフとアルテム・トリシキンを挙げたい。

そして、アナトリーの記事を品質の基準やプロフェッショナリズムの指標として受け入れてきた私は、彼らのフォーマットを自分の素材に「試着」し、その非互換性を認識せざるを得なかった。アプローチや実現方法の違いはあまりにも大きい。したがって、私は自分のスタイルを見つけ、磨き上げなければならない。

[Реter Konow]

MT5のビジュアルGUIエディターでの作業プロセス。

4年前：

(画像をクリック）。

追伸：デモの背景は以下の投稿に概説されています。

[Реter Konow]

時は流れ、ビジュアルエディターというアイデアは私の心の中で生き続けている。それは私から離れようとしない。そして、暇を見つけては考えている。- もう作ったのに、スイッチが入らないんだ。"

ビジュアルエディターの基本的な機能は私の実装にすでに存在しており、複雑なツールだけが欠けている。しかし、複雑なものはマークアップ言語を通して作成することができ、実際にはビジュアルモードよりもはるかに速く便利である。

例えば、テーブルやツリーリストは、手作業で作成するのは時間がかかるし大変だが、kibコードで書くのは早くて簡単だ......特にテンプレートを使う場合は。特にテンプレートを使う場合は。テーブルやリストはコピー・ペーストだけで作成できるのに、なぜわざわざ面倒なビジュアル編集ツールを開発する必要があるのでしょうか？意味がないのは明らかだ。しかし、では何が問題なのだろうか？

それは簡単だ。マークアップ言語とビジュアルエディターの現在の機能を組み合わせることだ。前者にも後者にも何か新しいものを加える必要はない。互いに補完し合うように組み合わせればいいのだ。

この問題を真剣に考えた結果、たとえ今、ビジュアルGUI構築に完全に切り替える機会があっても、私は拒否するという結論に達した。その理由は、マークアップ言語環境でkib-codeテンプレートや要素やプロパティの単純なコピー・ペーストを使う機会を失いたくないからだ。これはあまりにも貴重な利点だ。おそらく、私だけでなく、将来自分の開発したものを共有したり、以前の開発の一部をコピーしたりできるようになるすべてのユーザーにとっても。なくてはならないものなのだ。

つまり、ビジュアル・エディタのためにマークアップ言語を諦めることは絶対に不可能なのだ。以前はよくわからなかったのだが......。

それで、今日の問題は、言語とビジュアルエディターの機能を調和させるシステムを開発することなんだ。そして実は、技術的にはとても簡単なことなのだ。(1)第一に、ビジュアルエディタに必要な機能はすべて数年前に書き上げ、テスト済みであること、(2)第二に、ここ数ヶ月の間に、マークアップ言語の重要なメカニズムが十分に強化され、ソフトウェアインターフェイス管理が追加されるなど、大幅なバージョンアップが行われたことである。言い換えれば、すべてが統合と融合の準備ができており、課題は、グラフィカル・インターフェースのモデリングと構築の過程で、両機能の衝突のない相互作用のコンセプトを考え抜くことだけである。

概念的には、マークアップ言語とビジュアル・エディターは実際に衝突している。

この作業を難しくしている理由はいくつかある：

GUI エレメントとウィンドウは、標準ではコードで記述されるが、上のGIFのようにビジュアル・エディターでも作成できることを思い出してほしい。

1) 最初のケースでも2番目のケースでも、コンストラクタの機能は、方法は異なるものの、グラフィカル・コアを構築します。しかし、ビジュアル・エディタの機能は、言語の機能よりも弱いため、作成された要素は、エディタを通してユーザーからの設定を完全に受け入れることはできません。設定はエディタを書くことで補うことができるが、そうなるとマークアップ言語が不要になり、コードテンプレートに頼る可能性がなくなるのでまずい。マークアップ言語を放棄することはできない。

2) ビジュアルモードで新しい要素やウィンドウを作成する場合、マークアップ言語はそれらを「見る」ことはできません。つまり、マークアップ言語はGUIの視覚的な構築中に更新されません。元のkibコードには何も「追加」されません。この事実は、ビジュアル・エディターとマークアップ言語の概念的な分離に再びつながります。これは矛盾である。

では、この状況でどうあるべきか、何をすべきか。2つの強力なGUI構築ツールの共生につながる妥協点とは？

その解決策を探ってみよう：

要点：インターフェイスのモデリングにおけるビジュアル・エディタの役割を制限し、言語機能は変更しない。現実的には、これは次のことを意味する：

1.ビジュアル・モードで新しい要素やウィンドウを作成することを拒否する。

2.ビジュアルエディタの設定ウィンドウを通して、ユーザーGUIの要素やウィンドウの位置を編集したりプロパティを設定したりできるようにする。この場合、エディタは値のオーバーライドを含む特別なファイルを書いて保存し、そこからカーネルにロードして要素に割り当てます。実際、これはエディタで「処理される」新しいタイプの要素テンプレートを意味します。これらのテンプレートはkib-codeテンプレートと衝突することはなく、テンプレートに設定されたプロパティ値を上書きするだけです。

これはエディタとマークアップ言語の効果的な共生だと私は考えています。

P.S.皮肉なことに、エディターと言語機能を融合させるというアイデアは、技術的には数日で実現可能であり、かなり現実的なのだが、ユーザーの作業におけるそれらの統合と相互作用のすべての詳細を考え抜くとなると......。それにはもっと時間がかかる。:)

追伸：しかし、主な結論は、これらは互いに補完し合いながら一緒に働くことができるし、そうすべきだということです。

[hini]

あなたがやりたいことは、非常に長い時間がかかり、あなたのソースコード開発に貢献できる人はほとんどいないでしょう。

[Реter Konow]

hini #:
あなたがやりたいことは、非常に長い時間がかかりそうだし、ソースコードも、ほとんど誰も貢献できないだろう。ほとんど誰も貢献できないだろう。

最初の意見には強く同意できない。ビジュアルエディタというコンセプトは4年前に考え出されただけでなく、技術的にも十分に実装されており、ユーザーは基本的なコントロールからシンプルな設定ウィンドウを簡単に組み立てることができる。例えば、デザイナーには、寸法とグリッドのある有益なマークアップがあり、プロパティを設定するパネルがあり、プロジェクトを保存してAPIファイルを印刷する機能があり、フレーム、画像、フォントのある同じ補助ウィンドウがあります。すべてがマークアップ言語と同じです。

しかし、ビジュアル・エディターを完成させるには、ファイル・ナビゲーターが必須です。ファイル・ナビゲーターは、プロジェクトのアップロードや保存のためにフォルダを選択する機能を提供する。

ファイルナビゲータに加えて、kib-codeのようなテンプレートの概念を開発する必要がある。ファイル・ナビゲーターがあれば、ビジュアル・エディターはビルドしたインターフェイスをプロジェクトとしてではなく、テンプレートとして保存できるようになります。結局、本質的には同じことなのだ。さらに、プロジェクト全体だけでなく、このプロジェクトの個別のウィンドウもテンプレートとして保存されます。ビルドされたコアの一部だけが保存され、それを別のプロジェクトにロードして、ユーザーは必要な要素を（上のgifに示したコピーによって）抽出し、プロジェクトからこのテンプレートを消すことができるからだ。ウィンドウとエレメントを消去する機能があります。以上です。

テーブルは、上のgifのボタンの例に従ってセルをコピーするだけで作ることができる。同じことだ。ツリーリストはもっと複雑だが...。でも、それがメインではない。

熱意があれば、1ヶ月でも1ヶ月半でもできる。しかし、今は記事の準備で忙しいので、この作業は先送りになっている。

他のプログラマーはこのプロジェクトを開発できないだろうという発言については......。そう、彼らはプロジェクトを直接開発することはできない。しかし、解決策を提供したり、経験や意見を共有したり、色やグラデーションを扱う機能を提供したりすることはできる。私はそのような交流や協力を歓迎する。