記事"MQLプログラムのグラフィカルインターフェイスのマークアップツールとしてのMQL 第1部"についてのディスカッション
記事をもう一度よく読んでみたが、マークアップ言語のコンセプトは見つからなかった。他の言語での実装やライブラリの借用の可能性についての考察はあるが、著者はまだコンセプトを構築していない。それがなければ、何かを借りたり修正したりする意味がない。
コンセプトは、コードを使わず、単純明快な言葉で説明し、技術の本質、つまり何がどのように機能すべきかを説明すべきである。しかし、記事の中にはコードや例などがあります。それらは何なのでしょうか？
マークアップ言語の設計」という章には、マークアップ言語の概念は含まれていません。著者は、マークアップ言語の技術について何も書いていないことに注意してください。それから、あなたはコントローラの階層構造（実際には説明していない）について話し、関係のない具体的なことに踏み込んでいます。
そのようなコンセプトはまだない。
別のガスケット。
38枚か55枚か？
部品は38個か55個か？
誰もがMQLフォーラムの記事で「戦争と平和」を書くことができるわけではありません。
4記事以上のサイクルの著者は見たことがない ))))
記事の素材はよく読まれているようですが、どこかに違和感があります。XAMLをベースにしているのでしょうか？ 残念ながら、私はWinFormsを除いて、C#の他の機能を使用していないのと同様に、それを勉強していませんし、使用していません。
一般的に、興味深い、次を見てみましょう、唯一の願いは、もう少し多くの写真です、私の意見では、材料は、あなたがそれを読むだけでは非常に乾いたように見えます。
著者のプロフェッショナリズムは、彼が最初から最後まで コンセプトと実装を担当できるのであれば、希望を抱かせる。最初の記事には、既製のライブラリを改造してマークアップ言語にしようという意図がうかがえる。私はそのような解決策の意味を信じていない。ライブラリ自体には限界があるし、マークアップ言語も弱いだろう。質的に新しいレベルの技術やキャンバス上のコントローラーがなければ - 「羊の皮」は価値がないし、作者が描画要素を取り上げるなら - 基本をやり直す必要がある。これには技術への深い理解と多くの時間が必要だ。作者が変数名（何千にもなる）や構文、ルールに固執する様子から判断すると、残念ながら完成には至らないだろう......。
しかし！これはまだ最初の記事だ。さてと...。
誰もがMQLのフォーラムで『戦争と平和』を記事にできるわけではない
4記事以上のサイクルの著者は見たことがない ))))
記事の素材はよく読まれているようですが、どこか違和感があり、何を基準にすればいいのかわからない - XAMLが基準になっているのか - 残念ながら、私はそれを勉強していないし、使っていないだけでなく、WinFormsを除いて、C＃の他の機能を使用していません
一般的に、興味深い、次を見てみましょう、唯一の願いは、もう少し多くの写真です、私の意見では、材料は、あなたがそれを読むだけでは非常に乾いたように見えます。
私はXAMLを勉強しようとしたが、最初からで、ユーモアの冗談が理解できなかった-なぜ、もう一つの言語を勉強するのか、しかも、極めて狭い専門的な。いずれにせよ、ある日突然、プログラムが動いたときに何かを "微調整 "したくなったり、インターフェイスをもっとフレキシブルにしたくなったりするだろう。マークアップ言語の利点は取るに足らないもので、まだそれを学ばなければならないことを考慮に入れると、それは非常に疑わしい。あるいは、私がXAMLの思想を理解していなかったのかもしれない。
XAMLを勉強しようとしたのは、ほんの最初からで、ユーモアの冗談が理解できなかった。なぜ別の言語を勉強するのか、それも非常に狭い範囲に特化した言語を、しかも可能性を広げるどころか狭めてしまうような言語を。いずれにせよ、ある日突然、プログラムが動いたときに何かを "微調整 "したくなったり、インターフェイスをもっとフレキシブルにしたくなったりするだろう。マークアップ言語の利点は取るに足らないもので、まだそれを学ばなければならないことを考慮に入れると、それは非常に疑わしい。あるいは、私がXAMLの思想を理解していなかったのかもしれない。
私たちは記事の著者を待ちますが、便利なXAMLが何であるか、検索の方向を与えるかもしれません、多分私は読むだろう、主なものは、実際には - 記事の結果はどうなるのか、それはどのように便利で機能的になりますが、現段階では、私はグラフィカルプリミティブのためのSBに満足している - ソースが利用可能で読みやすい。
SZY：新しい言語についてですが、まあ、すべては相対的なものです。私はSBを使って.bmpでいくつかのグラフを保存したかったのですが...1日では理解できず、ググりました。15分でGoogle Chartsを知り、.bmpの代わりに.htmlを生成しました！;)
XAMLを勉強しようとしたのは、ほんの最初からで、ユーモアの冗談が理解できなかった。なぜ別の言語を勉強するのか、それも非常に狭い範囲に特化した言語を、しかも可能性を広げるどころか狭めてしまうような言語を。いずれにせよ、ある日突然、プログラムが動いたときに何かを "微調整 "したくなったり、インターフェイスをもっとフレキシブルにしたくなったりするだろう。マークアップ言語の利点は取るに足らないもので、まだそれを学ばなければならないことを考慮に入れると、それは非常に疑わしい。あるいは、私がXAMLの思想を理解していなかったのかもしれない。
XAMLの大きな価値は、あらゆる種類のダイアログウィンドウやその他の無意味なものの開発を簡素化することだ。MFCでは、標準と違う外観のリストを作るのは簡単ではなく、努力しなければならないが、ここでは1回か2回だ。いじり倒していると頭が痛くなるが、インターフェイスを作る必要があれば、使いこなせばいい。でも、インターフェイスを作る必要があるなら、使いこなすことができる。すぐにではありませんが、習得するにつれて本当に時間の節約になります。
皆さん、結果が見えないのに、なぜ最初の記事からその人を非難するのですか？私は一度もここにコメントを書いたことがなかったが、あなたのコメントを見て書いた。
私はプロのプログラマーではなく、アマチュアです。そして、ここでの多くの記事は、たとえ失敗したものであっても、私にもっと良い解決策を探させ、プログラミング言語をより深く勉強させる。なぜ著者がその問題を解決するための特別な方法を実装したのかを理解するためだ。自分の開発に何かを応用するために。どんな記事でも、ただ本やドキュメントを読むよりも何倍も知識量を増やしてくれる。
簡単な例を挙げよう。ここにはすでにGUIに関する記事がいくつもあるが、すべてクラスの助けを借りながらも手続き的なスタイルで実装されている。これは面倒で不便だ。最初から最後までコード全体を理解する必要がある。C++やC#のように、仮想メソッドをオーバーライドすることで、例えばダブルクリックのように、荒野に入り込むことなく自分の望むものを実装できる他の言語に目を向けるようになった。
デザインパターンや動的なデータ構造について 勉強し始めた。標準的なクラスはすべて書き直さなければならなかった。CObjectから始めた。最終的には、OnTradeTransaction、OnChartEvent、OnTimerイベント処理の簡単な実装を「本物の」OOPを使って書きました。私はXAMLマークアップに詳しくないので、勉強しようとしたときはとても面倒に思えたが、今は著者の伝えたいことを理解するためにXAMLに入り込み、著者のアイデアのいくつかを自分で実装する機会を得た。
だから、どんな記事でも鋭く批判する前に、私のように同じテーマについて違う見方を必要としている人がいると考えてほしい。あなたがより深い知識を持っているならば、提案し、導いてください。チームを組んで。記事をボロクソに言うよりも、その方が生産的だろう。
- www.mql5.com
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
新しい記事 MQLプログラムのグラフィカルインターフェイスのマークアップツールとしてのMQL 第1部 はパブリッシュされました:
この論文では、MQLの構造体を用いて、MQLプログラムのウィンドウインタフェースを記述するための新しい概念を提案します。 特別なクラスは、表示可能なMQLマークアップをGUI要素に変換し、管理し、プロパティを設定し、イベントを統一的に処理することができます。 また、標準ライブラリのダイアログや要素にマークアップを使用する例をいくつか紹介します。
なぜレイアウトがコードから分離され、特殊な言語で記述されているのでしょうか。 そのアプローチの基本的なメリットをご紹介します。
MQL環境の場合、問題を解決するために、ほんの数ショットを行っただけです。 特に、ビジュアルダイアログデザイナーについては、オブジェクトクラスの設計と構築方法の記事で紹介しています。 これはMAterWindows ライブラリをベースに動作します。 しかし、レイアウトの配置方法やサポートされている要素タイプのリストはかなり限定されています。
ビジュアルデザイナーがいないそれにも関わらず、より高度なレイアウトシステムは GUIコントロールのためのレイアウトとコンテナの使用 CBox クラス と CGrid クラス の記事で提案されています。 CWndObjやCWndContainerから継承した標準の制御要素やその他の要素をすべてサポートしていますが、コンポーネントの作成や配置を目的としたルーチンコーディングはユーザに任せています。
概念的には、コンテナを使ったこのアプローチは高度なものです（実質的にすべてのマークアップ言語でマークアップしていることを述べれば十分でしょう）。 つまり、その点に気をつける必要があります。 以前の記事（トレードにおけるOLAPの適用（その2）。インタラクティブな多次元データ分析結果の可視化)では、コンテナCBoxとCGridの修正と、"ラバー "プロパティをサポートするためのコントロール要素を提案しました。 以下では、その際の開発を利用して、標準ライブラリのオブジェクトに代表される要素を自動的に配置するという問題を解決するために、改良していきます。
作者: Stanislav Korotky