記事"MQLプログラムのグラフィカルインターフェイスのマークアップツールとしてのMQL 第1部"についてのディスカッション - ページ 3 123456 新しいコメント Реter Konow 2020.04.01 16:51 #21 Stanislav Korotky:XMLはないだろう。要はMQLなしでやるということだ。ゴールはMQLに "ネイティブな "MVPレベルのマークアップシステムを作ることだ。飾り気はないが、機能的 で、必要な人には 十分な 拡張性がある。 内部構造に立ち入らないことも可能だろう。 ただ、コンセプトや装置の説明がないよりはあったほうがいいというのが普通だ。... グラフィカルなライブラリや マークアップ言語、ビジュアルエディタのユーザーは実際にはいない（いるかもしれないが、見かけない）。学ぶことに熱心な人はいる。記事にマークアップ言語のコンセプトがなければ意味がありません。 コンセプトを書いてください。幸運を祈る。 Dmitry Fedoseev 2020.04.01 17:01 #22 Реter Konow:グラフィカルなライブラリやマークアップ言語、ビジュアルエディタのユーザーはいない（いるかもしれないが、目に見えない）。学ぼうとしている人はいる。記事にはマークアップ言語のコンセプトがなければ意味がありません。 コンセプトを書いてください。頑張って。 意味はある。記事には言語がなく、コンセプト自体もないのか？ Dmitry Fedoseev 2020.04.01 17:01 #23 このマークアップ言語が標準ライブラリに 限定されている場合、そのライブラリを使ったGUIの作成を簡素化する最善の解決策は、そのライブラリの通常のリファレンスマニュアルだろう。 Реter Konow 2020.04.01 17:06 #24 Dmitry Fedoseev:意味？記事の中に言葉がないのではなく、概念そのものがないのですか？ 著者はマークアップ言語がどのように機能するのかを説明していない。マークアップ言語はどのように機能するのか」と質問し、記事の中に詳細な答えを見つけてください。ない。 Dmitry Fedoseev 2020.04.01 17:22 #25 Реter Konow:著者はマークアップ言語がどのように機能するのか説明していない。マークアップ言語はどのように機能するのか」と質問し、記事の中に詳細な答えを見つけてください。ない。 おそらく次号に掲載されるだろう。 Реter Konow 2020.04.01 17:24 #26 Dmitry Fedoseev:おそらく次号に掲載されるだろう。 私も次号に載ると思っていた。私たちは単純な人間じゃない。みんな理解している。 Dmitry Fedoseev 2020.04.01 18:44 #27 Stanislav Korotky:XMLはないだろう。要はMQLなしでやるということだ。ゴールはMQLに "ネイティブな "MVPレベルのマークアップシステムを作ることだ。飾り気はないが、機能的で、必要な人には十分な拡張性がある。内部構造に立ち入らないことも可能だろう。ただ、コンセプトや装置の説明がないよりはあったほうがいいというのが普通だ。私も標準ライブラリに 熱狂しているわけではないが、選択肢があまりないので、（今のところ）数少ない超小型ライブラリと超派手なライブラリの間の最適な妥協点だ。素朴な技巧を根拠にそう宣言しているプログラミングやGUI制作の著名人と思われる人たちは、自分のスレッドでその手腕を発揮することをお勧めする。 具体的に誰のことですか？特に、これは複数形であり、ここには私たちの多くはありません。単数形なら、ピーターのことだと思うが...。でも複数形だ。疑問が生じる。 なぜファーストネームにしないの？そうすれば余計な疑問が生じない。それとも、空気を蹴ることはできないの？ Реter Konow 2020.04.01 19:39 #28 記事の話題に。5回目にして、私は全体を注意深く、中立的に、できるだけ客観的に読み直した。そして結論はこうだ： 1.記事の冒頭で、著者は読者にプログラムにおけるGUIの関連性について明確かつ明快に論じている。MQLで利用可能なグラフィカル・ツール、MTオブジェクト、ライブラリ、さらにはビュー・エディターについて述べている。GUIはむしろ必要であると主張する。これはこの記事のわかりやすく楽しい部分である。 2.アクセラレーションが始まる。著者は標準ライブラリ・ コードの例を挙げ、それを当然のように批判する。同情は彼の側にある。 3.次に、著者は他の言語におけるGUIの議論に移り、レイアウトの記述がプログラムコードから賢明に分離され、インターフェースのルーチンレイアウトを簡素化する独立した枝を表していることを正しく指摘している。彼はその利点を挙げている。今回、著者は文学、.Netプラットフォーム、アンドロイド、XML......などの一般的なフレーズを使い、言及している。彼は、ここでもここでも、すべてが「1つのフラコン」の中にあり、階層が可視化され、「単一のコントローラー」も定義されていると言う。彼は明確にせず、ただ続ける。悟っていない者にとっては、明確さは終わり、すべてが霧の中に沈む。どこで、何を、なぜ...。 4- 著者は「飛んで」しまい、読者との対話は高速モノローグに変わる。質問／テーマ／解決策／例／コード......すべてがごちゃ混ぜになる。もちろんテレパスには難しくないが、それ以外の人には難しい。著者は新しい言語の解決策をその場で考え、記事の最後までにすべてを終わらせようとしているようだ。口出しするな、全部やってやる！」みたいな。必死のリズムで、思考の断片、コード、変数やメソッドの名前（もしかしたら誰かに知られているかもしれない...）が飛び交う。ジャンプはますます頻繁になり、文と文のつながりを探すのに頭が対応できなくなる。読むのが本当に難しくなる。 5.読者との対話は最初の2章で失われ、さらに読んでも何もはっきりしなかった。一生懸命読んだのだが。著者はいったい何を示唆しているのか」という疑問が残った。 私は記事を閉じ、シミの例と最初の段落以外は何も思い出せなかった。それ以外のことは霧の中に溶けてしまった。 願わくば次号では、著者が読者との対話を続け、記事の最後まで物語構造を保ってくれることを。 ありがとう。 Алексей Мокрушин 2020.04.01 19:51 #29 ドミトリー・フェドセーエフ、不快ではあるが、非常に面白いビデオ挿入。長い間笑ってしまった。あなたが強調した部分を読んで、本当にバカに見えることに気づいた。書き直したのではなく、改善・補足したと言った方が正確だろう。私は、あなたがこのサイトに登場して5年間、あなたの記事をたくさん読んできたし、あなたの知識が私よりはるかに豊富であることを信じて疑わないが、エクスプレス・ライティングに OOPが必要ないという意見には同意できない。グラフィカル・インターフェースを使ったり、1つのEAで複数のTSを組み合わせたり、統計を取ったり、といった複雑なプログラムでは、OOPはプログラムのコードをよりよく構造化するために大いに役立ちますし、デザイン・パターン（私はまだ勉強のごく初期ですが）はOOPの力を何倍にもしてくれます。もちろん、小さなEAにOOPを押し込めば、普通のプロシージャが使えるようになり、書くスピードが何倍にもなるという意味ではありません。もし興味があれば、私がOOPと1つのテンプレートを適用した例と、それによって私の生活がどのように簡素化されたかを説明します。また、ドミトリーさんの「関数へのポインタがありながら、OOPを使って デリゲートのアナログを作成することはさらに 難しい」という言葉を例に挙げて説明してもらえますか？あるいは、どの記事で関数ポインタについての情報を見つけることができますか？よろしくお願いします。 Artyom Trishkin 2020.04.01 20:00 #30 Алексей Мокрушин: ドミトリー・フェドセーエフ、不快ではあるが、非常に面白いビデオ挿入。長い間笑ってしまった。あなたが強調した部分を読んで、本当にバカに見えることに気づいた。書き直したのではなく、改善・補足したと言った方が正確だろう。私は、あなたがこのサイトに登場して5年間、あなたの記事をたくさん読んできたし、あなたの知識が私よりはるかに豊富であることを信じて疑わないが、エクスプレス・ライティングに OOPが必要ないという意見には同意できない。グラフィカル・インターフェースを使ったり、1つのEAで複数のTSを組み合わせたり、統計を取ったり、といった複雑なプログラムでは、OOPはプログラムのコードをよりよく構造化するために大いに役立ちますし、デザイン・パターン（私はまだ勉強のごく初期ですが）はOOPの力を何倍にもしてくれます。もちろん、小さなEAにOOPを押し込めば、普通のプロシージャが使えるようになり、書くスピードが何倍にもなるという意味ではありません。もし興味があれば、私がOOPと1つのテンプレートを適用した例と、それによって私の生活がどのように簡素化されたかを説明します。また、ドミトリーさんの「関数へのポインタがありながら、OOPを使って デリゲートのアナログを作成することはさらに 難しい」という言葉を例に挙げて説明してもらえますか？あるいは、どの記事で関数ポインタについての情報を見つけることが できますか？よろしくお願いします。 すべてはドキュメントにあります。 123456 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
XMLはないだろう。要はMQLなしでやるということだ。ゴールはMQLに "ネイティブな "MVPレベルのマークアップシステムを作ることだ。飾り気はないが、機能的 で、必要な人には 十分な 拡張性がある。 内部構造に立ち入らないことも可能だろう。 ただ、コンセプトや装置の説明がないよりはあったほうがいいというのが普通だ。
...
グラフィカルなライブラリや マークアップ言語、ビジュアルエディタのユーザーは実際にはいない（いるかもしれないが、見かけない）。学ぶことに熱心な人はいる。記事にマークアップ言語のコンセプトがなければ意味がありません。 コンセプトを書いてください。幸運を祈る。
グラフィカルなライブラリやマークアップ言語、ビジュアルエディタのユーザーはいない（いるかもしれないが、目に見えない）。学ぼうとしている人はいる。記事にはマークアップ言語のコンセプトがなければ意味がありません。 コンセプトを書いてください。頑張って。
意味はある。記事には言語がなく、コンセプト自体もないのか？
意味？記事の中に言葉がないのではなく、概念そのものがないのですか？
著者はマークアップ言語がどのように機能するのかを説明していない。マークアップ言語はどのように機能するのか」と質問し、記事の中に詳細な答えを見つけてください。ない。
著者はマークアップ言語がどのように機能するのか説明していない。マークアップ言語はどのように機能するのか」と質問し、記事の中に詳細な答えを見つけてください。ない。
おそらく次号に掲載されるだろう。
おそらく次号に掲載されるだろう。
私も次号に載ると思っていた。私たちは単純な人間じゃない。みんな理解している。
XMLはないだろう。要はMQLなしでやるということだ。ゴールはMQLに "ネイティブな "MVPレベルのマークアップシステムを作ることだ。飾り気はないが、機能的で、必要な人には十分な拡張性がある。内部構造に立ち入らないことも可能だろう。ただ、コンセプトや装置の説明がないよりはあったほうがいいというのが普通だ。
私も標準ライブラリに 熱狂しているわけではないが、選択肢があまりないので、（今のところ）数少ない超小型ライブラリと超派手なライブラリの間の最適な妥協点だ。
素朴な技巧を根拠にそう宣言しているプログラミングやGUI制作の著名人と思われる人たちは、自分のスレッドでその手腕を発揮することをお勧めする。
具体的に誰のことですか？特に、これは複数形であり、ここには私たちの多くはありません。単数形なら、ピーターのことだと思うが...。でも複数形だ。疑問が生じる。
なぜファーストネームにしないの？そうすれば余計な疑問が生じない。それとも、空気を蹴ることはできないの？
記事の話題に。5回目にして、私は全体を注意深く、中立的に、できるだけ客観的に読み直した。そして結論はこうだ：
1.記事の冒頭で、著者は読者にプログラムにおけるGUIの関連性について明確かつ明快に論じている。MQLで利用可能なグラフィカル・ツール、MTオブジェクト、ライブラリ、さらにはビュー・エディターについて述べている。GUIはむしろ必要であると主張する。これはこの記事のわかりやすく楽しい部分である。
2.アクセラレーションが始まる。著者は標準ライブラリ・ コードの例を挙げ、それを当然のように批判する。同情は彼の側にある。
3.次に、著者は他の言語におけるGUIの議論に移り、レイアウトの記述がプログラムコードから賢明に分離され、インターフェースのルーチンレイアウトを簡素化する独立した枝を表していることを正しく指摘している。彼はその利点を挙げている。今回、著者は文学、.Netプラットフォーム、アンドロイド、XML......などの一般的なフレーズを使い、言及している。彼は、ここでもここでも、すべてが「1つのフラコン」の中にあり、階層が可視化され、「単一のコントローラー」も定義されていると言う。彼は明確にせず、ただ続ける。悟っていない者にとっては、明確さは終わり、すべてが霧の中に沈む。どこで、何を、なぜ...。
4- 著者は「飛んで」しまい、読者との対話は高速モノローグに変わる。質問／テーマ／解決策／例／コード......すべてがごちゃ混ぜになる。もちろんテレパスには難しくないが、それ以外の人には難しい。著者は新しい言語の解決策をその場で考え、記事の最後までにすべてを終わらせようとしているようだ。口出しするな、全部やってやる！」みたいな。必死のリズムで、思考の断片、コード、変数やメソッドの名前（もしかしたら誰かに知られているかもしれない...）が飛び交う。ジャンプはますます頻繁になり、文と文のつながりを探すのに頭が対応できなくなる。読むのが本当に難しくなる。
5.読者との対話は最初の2章で失われ、さらに読んでも何もはっきりしなかった。一生懸命読んだのだが。著者はいったい何を示唆しているのか」という疑問が残った。
私は記事を閉じ、シミの例と最初の段落以外は何も思い出せなかった。それ以外のことは霧の中に溶けてしまった。
願わくば次号では、著者が読者との対話を続け、記事の最後まで物語構造を保ってくれることを。
ありがとう。
ドミトリー・フェドセーエフ、不快ではあるが、非常に面白いビデオ挿入。長い間笑ってしまった。あなたが強調した部分を読んで、本当にバカに見えることに気づいた。書き直したのではなく、改善・補足したと言った方が正確だろう。私は、あなたがこのサイトに登場して5年間、あなたの記事をたくさん読んできたし、あなたの知識が私よりはるかに豊富であることを信じて疑わないが、エクスプレス・ライティングに OOPが必要ないという意見には同意できない。グラフィカル・インターフェースを使ったり、1つのEAで複数のTSを組み合わせたり、統計を取ったり、といった複雑なプログラムでは、OOPはプログラムのコードをよりよく構造化するために大いに役立ちますし、デザイン・パターン（私はまだ勉強のごく初期ですが）はOOPの力を何倍にもしてくれます。もちろん、小さなEAにOOPを押し込めば、普通のプロシージャが使えるようになり、書くスピードが何倍にもなるという意味ではありません。もし興味があれば、私がOOPと1つのテンプレートを適用した例と、それによって私の生活がどのように簡素化されたかを説明します。また、ドミトリーさんの「関数へのポインタがありながら、OOPを使って デリゲートのアナログを作成することはさらに 難しい」という言葉を例に挙げて説明してもらえますか？あるいは、どの記事で関数ポインタについての情報を見つけることが できますか？よろしくお願いします。
すべてはドキュメントにあります。