私のアプローチコアはエンジンです。 - ページ 26 1...192021222324252627282930313233...184 新しいコメント Igor Makanu 2018.12.08 07:31 #251 Koldun Zloy:GUIコンストラクタは、特定のグラフィックライブラリ用に作られています。MQLのGUIビルダーがあるとしたら、ここだろう。私はどこかのハブレで、「PythonのGUIコンストラクタを作る」みたいな記事を見たことがあるので、もしかしたら誰かが自分のコードを追加できるマルチプラットフォームGUIを見たことがあるのかもしれないと思ったのですが......。 でも、ゼロからコンストラクタを書くなら、むしろMQLを使う方がいいんです。 Реter Konow 2018.12.08 07:44 #252 Igor Makanu:1.シャープで開発したことはなく、興味もありませんでしたが、5年ほど前にDelphiを使って.dllとボタンやフォームを接続して問題なく動きました。しかも、1日で全てのプロジェクトをDelphiで書きました。標準フォームが動かない理由を見つけるのに半日費やしましたが、システムウィンドウを呼び出して接続したら全て正常に動きました。 .dllの接続、標準的なミューテックスとの同期に問題はありません。ターミナルに接続するためにスレッドを開始し、それだけですべてが勝手に進みます。別に.dllのフォーム、別にMTは誰も待っていません。 SZS: Delphiは.dllを作るにはかなり非現実的ですが、手元にあったもの（その時座っていたもの）を使いましたのでご注意ください)) 2.ただ、ポイントとしては、なぜMT toolkitの標準 クラスを使えないのかが理解できません。グラフィックの作成プロセスを統一できたらかっこいいし、不要なボタン/ダイアログなどをコメントできるユニバーサルインクルージョンになるかもしれませんね。1.これは、とても、素人的な問題の捉え方です（悪気はないのですが）。1日で終わるプロジェクトは、プロジェクトとは言いません。小さな仕事です。 10個のウィンドウからなるアプリケーションを作成し、その中に大きなデータテーブル、設定ウィンドウ、ダイアログボックスがあるとします。Delphiで描画するんですね。そして、DLLを作成するのです。そして、それをMTプロジェクトに接続するのです。 MTアプリケーションは、DelphiのGUIと共有メモリで接続する必要があります。関数とコントロールを接続し、データをテーブルセルに接続します。アプリケーションの2つの部分の複雑な相互作用を整理して、きちんと考える必要があります。 GUIとMTアプリケーションの2つのパート間で、パラメータの値の交換と同期動作が必要です。 もう一度言いますが、もしあなたのアプリケーションが大規模で深刻なもの（テーブル、設定ウィンドウ、ダイアログボックス、古代のリストなど）であれば、DLLを介して2つのパーツからなる1つのまとまった効率的な作品を作ることは非常に重大な仕事です。やったことがあるからわかるんです。 しかも、1日でできるような小さな作業の話でしょう。本気じゃないんです。 一昔前の標準ライブラリが使える。しかし、問題は必要な労力と得られる結果です。どんなものですか？アナトリーは標準ライブラリを足がかりにして、独自のライブラリを作っていましたね。しかし、標準ライブラリでも動くのに、なぜそんなことをしたのだろう？答えは簡単で、彼はより質の高いものをすべて実装し、Standard Libraryの枠を超えたのです。しかし、大量流通を実現するには、使いにくさを軽減することが必要です。使いやすければ使いやすいほど、-ユーザーが増える（もちろん品質も向上する）。 Igor Makanu 2018.12.08 08:13 #253 Реter Konow:1.これは、とても、素人的な問題の捉え方です（悪気はないのですが）。1日で終わるプロジェクトは、プロジェクトとは言いません。小さな仕事です。10個のウィンドウからなるアプリケーションを作成し、その中に大きなデータテーブル、設定ウィンドウ、ダイアログボックスがあるとします。Delphiで描画するんですね。そして、DLLを作成するのです。そして、それをMTプロジェクトに接続するのです。MTアプリケーションは、DelphiのGUIと共有メモリで接続する必要があります。関数とコントロールを接続し、データをテーブルセルに接続します。アプリケーションの2つの部分の複雑な相互作用を整理して、きちんと考える必要があります。GUIとMTアプリケーションの2つのパート間で、パラメータの値の交換と同期動作が必要です。もう一度言いますが、もしあなたのアプリケーションが大規模で深刻なもの（テーブル、設定ウィンドウ、ダイアログボックス、古代のリストなど）であれば、DLLを介して2つのパーツからなる1つのまとまった効率的な作品を作ることは非常に重大な仕事です。やったことがあるからわかるんです。しかも、1日でできるような小さな作業の話でしょう。これは本気ではない。不満な点は何ですか？MTと.dllのデータ交換は、世界と同じくらい古いものだということを理解していないだけだ 以前はMTにまともなグラフィックが無かったので、ボタンやパネルが欲しくて.dllを作っていたのですが テーブル？- テーブルを描く、操作する？- を描く...あなたはちょうどタスクを分離することはできません、同じDelphiでは、データベースのデータベースを作成 し、それらを操作するための両方の多くの既製のコンポーネントがあります MTからすなわち、あなただけのデータ自体を必要とし、残りはサードパーティのプログラムを行います、あなたはそれのためにあなたの言葉を取ることができますが、同じデルファイで表、グラフなどの出力と、データベースとの仕事を書くために一日の仕事;) MTにおけるデータとは？= それは単なるティックとバーであり、.dllの中で「競争」する意味はありません - 一度すべてをファイルにダンプし、サードパーティのプログラムでそのファイルを操作してください。 SZS：誰かが最近フォーラムで、現代のIT企業は、彼らが働いているコードを徹底的に理解していない従業員を大切にしますが、できるだけ早く大量のタスクを実行できる人、すなわち、自分のタスクに他の人の仕事を統合することができる必要があり、毎回すべてのゼロから構築しない！ と書きました。私はあなたの主な職業を知らない、私はプログラマとして働いたことがないが、私は常に関連分野で働いている、長い間、産業用コントローラ、ACSとACSのメンテナンスに従事し、プログラムのソリューションを追加し、開発者と対話しなければならなかったので、私はすべての既製のソフトウェアソリューションに取得しなければならなかった - ここでは、ゼロからすべてを書くことができない )))と産業 "鉄 "のメーカーが専門プログラミングシステム、ここでC、SCADA、およびアセンブラ、一度他の誰かのコードを読むことができる必要がある使用します;)) その「エンジン」に基づいて、プログラマーがこれ以上修正できないような、条件付きで実行可能なデザインを作ろうというのですか？ Реter Konow 2018.12.08 08:56 #254 Igor Makanu:辛い思いとは？MTと.dllのデータ交換は、世界と同じくらい古いものだということを理解していないだけだ 以前はMTにまともなグラフィックが無かったので、ボタンやパネルが欲しくて.dllを作りました。 テーブル？- テーブルを描く、操作する？- を描く...あなたはちょうどタスクを分離することはできません、同じDelphiでは、データベースのデータベースを作成し、それらを操作するための両方の多くの既製のコンポーネントがあります MTからすなわち、あなただけのデータを必要とし、残りはサードパーティのプログラムを行います、あなたはそれのためにあなたの言葉を取ることができますが、同じデルファイで表、グラフなどの出力と、データベースとの仕事を書くために一日の仕事;) ZS：MTにおけるデータとは？= それは単なるティックとバーであり、.dllを通して履歴を「レース」する意味はありません - 一度すべてをファイルにダンプし、サードパーティのプログラムでそのファイルを操作してください。MTから入ってくるデータだけを取り出して、DLLを通してDelphiやC++やC#で書かれたアプリケーションに渡すのであれば、間違いなく可能 でしょう。 そうすると、トレーディング・アプリケーションは完全に別のプログラミング言語で書かれることになる。 つまり、時系列、テスター、最適化、合成、その他多くのものを別の言語で作成する必要があるのです。 なぜMQLが全く必要ないのか？サードパーティーのアプリケーションに直接データを供給し、イベントやオーダーの送り手としてプラットフォームを利用すれば十分です。そして、それだけです。しかし、トレーディングシステム言語としてのMQLの良さは失われて しまう。 なぜMQLが必要なのか？ なぜなら、MQLはトレーディングアプリケーションを書くために開発されたアプリケーション言語だからです。これが最大のメリットです。軽くてシンプルなのがいい。プログラマー向けの既成のソリューションがたくさんあります。取って使っているのです。 プログラマーには選択肢がある。 取引アプリケーションをサードパーティ言語（C++、C#、Delphiなど）で作成し、MTをデータソースおよびオーダートランスミッタとして接続します。(この場合、プラットフォームツールキットを使用したい場合は、再作成する必要があります）。プラットフォーム・ツールキットとMQLを使用しながら、別の言語でGUIを実装し、MTアプリケーションに接続する「二頭身」アプリケーションを作成します。(アプリケーションが本気なら、めんどくさい）。 アプリケーション全体をMQLで記述し、プラットフォームのすべての利点と利益を利用することができます。(この場合、GUIを作成することに問題があります）。 もちろん、MQLとMTを使うのが最も好ましい。なぜなら、テスト、最適化、研究（合成）、指標、便利な関数、時系列などの 利点があるからだ。+ フォーラムでの技術的な言語サポート。 しかし、この理想には重大な欠点があります。それは、質の高いGUIを作るのが難しいため、複雑なアプリケーションを作るには限界が あることです。 この最後の問題は、ほぼ 解決しました。 だから、いざ実践で本格的にアプリケーションを書き始めると、必ずMTを選ぶことになる。他の多くの人たちもそうでしょう。 Реter Konow 2018.12.08 09:10 #255 Igor Makanu:... エンジン」をベースに、プログラマーがこれ以上修正できないような、条件付きで実行可能なデザインを作ろうということでしょうか？エンジンは、私のコンストラクタで作成されるそのGUIの「キャリア」です。修正する必要はありません。アプリケーションに接続するだけで、作成したGUIは動作します。 Yury Kulikov 2018.12.08 09:24 #256 Реter Konow:もう一度言いますが、もしアプリケーションが大規模で深刻なもの（テーブル、設定ウィンドウ、ダイアログ、古代のリストなど）であれば、DLLを介して2つの部分の一貫した効率的な操作を作成することは非常に重大なタスクとなります。やったことがあるからわかるんです。レタグ・コノウMQLでアプリケーションを完全に書き上げ、そのプラットフォームの利点と長所をすべて利用すること。(この場合、GUIを作成することに問題があります）。大規模で複雑なアプリケーションを作ることができる人は、間違いなくguiライブラリを使うでしょう。例えば、アプリケーションを開発していて、アニメーションを 追加することになった場合、開発者はどうすればいいのでしょうか？彼はあなたを捜して尋ねるべきか、それともすべてを壊してゼロから作り直すべきか？ GUI作成に問題があるというのは、どこから出てきたのでしょうか。市場を見てみると、GUIを使ったアプリケーションはたくさんあります。 Реter Konow 2018.12.08 09:33 #257 Yury Kulikov:1.大規模で複雑なアプリケーションを作ることができる人は、間違いなくguiライブラリを使うでしょう。 2.アプリケーションの開発中に、例えばアニメーションを追加することになった場合、開発者はどうすればいいのでしょうか？検索して聞くか、全部壊して一から作るか？3）また、GUI作成に問題があるというのはどこから出てきたのでしょうか。マーケットプレイスを見てください、GUIを使ったアプリがたくさんあります。1.GUIライブラリは、本格的なプログラマーのために設計されたライブラリです。使い方が難しいため、大量生産はできない。そ れのどこがいいんだ？ただ、ライブラリを熟読して複雑なアプリケーションを作る人もいれば、そうでない人もいるのでしょうか？ 2.開発者がアプリケーションでアニメーションを 作成するようにします。私と何の関係があるのですか？このアニメーションをGUIやEngineから独立して呼び出したり、アニメーションの呼び出しを何らかのボタンにリンクさせたりすることができる。 3)GUIが注目されるのは数人しかいない。あなたと、アナトリーと、あと誰か...。あとは、少しも深刻なレベルには達していない。 Yury Kulikov 2018.12.08 09:48 #258 Реter Konow: 3.GUIが注目される人は少数派です。私なら、そう断言はしませんね。しかも、guiライブラリの開発ではなく、guiアプリケーションの話だったんです。市場には、独自に開発したものを使っているもの、標準のライブラリを使っているもの、Anatolyのライブラリを使っているものなど、さまざまなものがあります。 Georgiy Merts 2018.12.08 09:50 #259 Реter Konow:1.そこがポイントで、GUIライブラリは本格的なプログラマーのために設計されています。使い方が難しいため、大量に普及させることはできない。そ れのどこがいいんだ？ライブラリを熟読して複雑なアプリケーションを作る人もいれば、そうでない人もいるのでは？2.開発者がアプリケーションでアニメーションを作成するようにします。私と何の関係があるのですか？このアニメーションをGUIやEngineから独立して呼び出したり、アニメーションの呼び出しを何らかのボタンにリンクさせたりすることができる。3)GUIが注目されるのは数人しかいない。あなたと、アナトリーと、あと誰か...。それ以外は、ちょっと深刻なレベルにも達していない。ピーター 一番の問題は、プロジェクトの 位置づけにあると思うんです。 プログラミングの経験が豊富で、かつ、手を動かすことが好きな参加者だけが楽しめる内容になっています。 多いと思いますか？ いいですか、このデザインを批判しているのは、普段から「マニュアル」取引をしていない人ばかりなんです。せいぜい、ときどき。そして、彼らはあなたのプロジェクトを「マニュアル」のトレーダーとして見ていないので、プログラマーとして見ているのです。そして、当然のことながら、非常に怪しげな解決策をたくさん見つけることができるのです。 私の意見では、今の質問は、このニッチ（私の意見では、非常に狭いもの）を見つけることであるべきです：手を動かすことを好むプログラマ。 Maxim Kuznetsov 2018.12.08 09:53 #260 Igor Makanu:ハブラのようなどこかで「PythonのGUIビルダーを作る」という記事を見た気がするので、自分でコードを追加できるマルチプラットフォームGUIを見たことがある人がいるかもしれないと思ったのですが......。コンストラクタを一から書くなら、むしろMQLを使ったほうがいい。最近のGUIコンストラクター（「フォームにボタンをばらまく」もの）は、かなり技術的なもので、そこにMQLの要素をくっつけると、ファンタスティックに見えない。 中間形式（プロジェクト ファイルなど）では、ほとんどすべてのものが、レイアウトや要素間の関係を記述したXMLを持っています。 ターゲットプラットフォームのコード生成は、実際にはXSLTの変換であり、Web開発者だと思えば誰でもできることです :-) 例えば、EasyAndFast（https://www.mql5.com/ru/code/19703）は、オブジェクトベースで、必要なコンポーネントがすべて揃っているからです。(そして、このスレッドとは異なり、方法で開いて文書化された)、、単にトランスレータを書きます。 gui-mqlのビルダーがいないのは、メガ・コンプレックスだからではなく、単に需要がないからです。 EasyAndFastGUI - библиотека для создания графических интерфейсов www.mql5.com Библиотека EasyAndFastGUI дает возможность создавать графические интерфейсы для своих MQL-программ. 1...192021222324252627282930313233...184 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
GUIコンストラクタは、特定のグラフィックライブラリ用に作られています。MQLのGUIビルダーがあるとしたら、ここだろう。
私はどこかのハブレで、「PythonのGUIコンストラクタを作る」みたいな記事を見たことがあるので、もしかしたら誰かが自分のコードを追加できるマルチプラットフォームGUIを見たことがあるのかもしれないと思ったのですが......。
でも、ゼロからコンストラクタを書くなら、むしろMQLを使う方がいいんです。
1.シャープで開発したことはなく、興味もありませんでしたが、5年ほど前にDelphiを使って.dllとボタンやフォームを接続して問題なく動きました。しかも、1日で全てのプロジェクトをDelphiで書きました。標準フォームが動かない理由を見つけるのに半日費やしましたが、システムウィンドウを呼び出して接続したら全て正常に動きました。
.dllの接続、標準的なミューテックスとの同期に問題はありません。ターミナルに接続するためにスレッドを開始し、それだけですべてが勝手に進みます。別に.dllのフォーム、別にMTは誰も待っていません。
SZS: Delphiは.dllを作るにはかなり非現実的ですが、手元にあったもの（その時座っていたもの）を使いましたのでご注意ください))
2.ただ、ポイントとしては、なぜMT toolkitの標準 クラスを使えないのかが理解できません。グラフィックの作成プロセスを統一できたらかっこいいし、不要なボタン/ダイアログなどをコメントできるユニバーサルインクルージョンになるかもしれませんね。
1.これは、とても、素人的な問題の捉え方です（悪気はないのですが）。1日で終わるプロジェクトは、プロジェクトとは言いません。小さな仕事です。
10個のウィンドウからなるアプリケーションを作成し、その中に大きなデータテーブル、設定ウィンドウ、ダイアログボックスがあるとします。Delphiで描画するんですね。そして、DLLを作成するのです。そして、それをMTプロジェクトに接続するのです。
MTアプリケーションは、DelphiのGUIと共有メモリで接続する必要があります。関数とコントロールを接続し、データをテーブルセルに接続します。アプリケーションの2つの部分の複雑な相互作用を整理して、きちんと考える必要があります。
GUIとMTアプリケーションの2つのパート間で、パラメータの値の交換と同期動作が必要です。
もう一度言いますが、もしあなたのアプリケーションが大規模で深刻なもの（テーブル、設定ウィンドウ、ダイアログボックス、古代のリストなど）であれば、DLLを介して2つのパーツからなる1つのまとまった効率的な作品を作ることは非常に重大な仕事です。やったことがあるからわかるんです。
しかも、1日でできるような小さな作業の話でしょう。本気じゃないんです。
一昔前の標準ライブラリが使える。しかし、問題は必要な労力と得られる結果です。どんなものですか？アナトリーは標準ライブラリを足がかりにして、独自のライブラリを作っていましたね。しかし、標準ライブラリでも動くのに、なぜそんなことをしたのだろう？答えは簡単で、彼はより質の高いものをすべて実装し、Standard Libraryの枠を超えたのです。しかし、大量流通を実現するには、使いにくさを軽減することが必要です。使いやすければ使いやすいほど、-ユーザーが増える（もちろん品質も向上する）。
1.これは、とても、素人的な問題の捉え方です（悪気はないのですが）。1日で終わるプロジェクトは、プロジェクトとは言いません。小さな仕事です。
10個のウィンドウからなるアプリケーションを作成し、その中に大きなデータテーブル、設定ウィンドウ、ダイアログボックスがあるとします。Delphiで描画するんですね。そして、DLLを作成するのです。そして、それをMTプロジェクトに接続するのです。
MTアプリケーションは、DelphiのGUIと共有メモリで接続する必要があります。関数とコントロールを接続し、データをテーブルセルに接続します。アプリケーションの2つの部分の複雑な相互作用を整理して、きちんと考える必要があります。
GUIとMTアプリケーションの2つのパート間で、パラメータの値の交換と同期動作が必要です。
もう一度言いますが、もしあなたのアプリケーションが大規模で深刻なもの（テーブル、設定ウィンドウ、ダイアログボックス、古代のリストなど）であれば、DLLを介して2つのパーツからなる1つのまとまった効率的な作品を作ることは非常に重大な仕事です。やったことがあるからわかるんです。
しかも、1日でできるような小さな作業の話でしょう。これは本気ではない。
不満な点は何ですか？MTと.dllのデータ交換は、世界と同じくらい古いものだということを理解していないだけだ
以前はMTにまともなグラフィックが無かったので、ボタンやパネルが欲しくて.dllを作っていたのですが
テーブル？- テーブルを描く、操作する？- を描く...あなたはちょうどタスクを分離することはできません、同じDelphiでは、データベースのデータベースを作成 し、それらを操作するための両方の多くの既製のコンポーネントがあります
MTからすなわち、あなただけのデータ自体を必要とし、残りはサードパーティのプログラムを行います、あなたはそれのためにあなたの言葉を取ることができますが、同じデルファイで表、グラフなどの出力と、データベースとの仕事を書くために一日の仕事;)
MTにおけるデータとは？= それは単なるティックとバーであり、.dllの中で「競争」する意味はありません - 一度すべてをファイルにダンプし、サードパーティのプログラムでそのファイルを操作してください。
SZS：誰かが最近フォーラムで、現代のIT企業は、彼らが働いているコードを徹底的に理解していない従業員を大切にしますが、できるだけ早く大量のタスクを実行できる人、すなわち、自分のタスクに他の人の仕事を統合することができる必要があり、毎回すべてのゼロから構築しない！ と書きました。私はあなたの主な職業を知らない、私はプログラマとして働いたことがないが、私は常に関連分野で働いている、長い間、産業用コントローラ、ACSとACSのメンテナンスに従事し、プログラムのソリューションを追加し、開発者と対話しなければならなかったので、私はすべての既製のソフトウェアソリューションに取得しなければならなかった - ここでは、ゼロからすべてを書くことができない )))と産業 "鉄 "のメーカーが専門プログラミングシステム、ここでC、SCADA、およびアセンブラ、一度他の誰かのコードを読むことができる必要がある使用します;))
その「エンジン」に基づいて、プログラマーがこれ以上修正できないような、条件付きで実行可能なデザインを作ろうというのですか？
辛い思いとは？MTと.dllのデータ交換は、世界と同じくらい古いものだということを理解していないだけだ
以前はMTにまともなグラフィックが無かったので、ボタンやパネルが欲しくて.dllを作りました。
テーブル？- テーブルを描く、操作する？- を描く...あなたはちょうどタスクを分離することはできません、同じDelphiでは、データベースのデータベースを作成し、それらを操作するための両方の多くの既製のコンポーネントがあります
MTからすなわち、あなただけのデータを必要とし、残りはサードパーティのプログラムを行います、あなたはそれのためにあなたの言葉を取ることができますが、同じデルファイで表、グラフなどの出力と、データベースとの仕事を書くために一日の仕事;)
ZS：MTにおけるデータとは？= それは単なるティックとバーであり、.dllを通して履歴を「レース」する意味はありません - 一度すべてをファイルにダンプし、サードパーティのプログラムでそのファイルを操作してください。
MTから入ってくるデータだけを取り出して、DLLを通してDelphiやC++やC#で書かれたアプリケーションに渡すのであれば、間違いなく可能 でしょう。 そうすると、トレーディング・アプリケーションは完全に別のプログラミング言語で書かれることになる。
つまり、時系列、テスター、最適化、合成、その他多くのものを別の言語で作成する必要があるのです。
なぜMQLが全く必要ないのか？サードパーティーのアプリケーションに直接データを供給し、イベントやオーダーの送り手としてプラットフォームを利用すれば十分です。そして、それだけです。しかし、トレーディングシステム言語としてのMQLの良さは失われて しまう。
なぜMQLが必要なのか？
なぜなら、MQLはトレーディングアプリケーションを書くために開発されたアプリケーション言語だからです。これが最大のメリットです。軽くてシンプルなのがいい。プログラマー向けの既成のソリューションがたくさんあります。取って使っているのです。
プログラマーには選択肢がある。
もちろん、MQLとMTを使うのが最も好ましい。なぜなら、テスト、最適化、研究（合成）、指標、便利な関数、時系列などの 利点があるからだ。+ フォーラムでの技術的な言語サポート。
しかし、この理想には重大な欠点があります。それは、質の高いGUIを作るのが難しいため、複雑なアプリケーションを作るには限界が あることです。
この最後の問題は、ほぼ 解決しました。
だから、いざ実践で本格的にアプリケーションを書き始めると、必ずMTを選ぶことになる。他の多くの人たちもそうでしょう。
...
エンジン」をベースに、プログラマーがこれ以上修正できないような、条件付きで実行可能なデザインを作ろうということでしょうか？
エンジンは、私のコンストラクタで作成されるそのGUIの「キャリア」です。修正する必要はありません。アプリケーションに接続するだけで、作成したGUIは動作します。
もう一度言いますが、もしアプリケーションが大規模で深刻なもの（テーブル、設定ウィンドウ、ダイアログ、古代のリストなど）であれば、DLLを介して2つの部分の一貫した効率的な操作を作成することは非常に重大なタスクとなります。やったことがあるからわかるんです。
大規模で複雑なアプリケーションを作ることができる人は、間違いなくguiライブラリを使うでしょう。例えば、アプリケーションを開発していて、アニメーションを 追加することになった場合、開発者はどうすればいいのでしょうか？彼はあなたを捜して尋ねるべきか、それともすべてを壊してゼロから作り直すべきか？
GUI作成に問題があるというのは、どこから出てきたのでしょうか。市場を見てみると、GUIを使ったアプリケーションはたくさんあります。
1.大規模で複雑なアプリケーションを作ることができる人は、間違いなくguiライブラリを使うでしょう。
2.アプリケーションの開発中に、例えばアニメーションを追加することになった場合、開発者はどうすればいいのでしょうか？検索して聞くか、全部壊して一から作るか？
3）また、GUI作成に問題があるというのはどこから出てきたのでしょうか。マーケットプレイスを見てください、GUIを使ったアプリがたくさんあります。
1.GUIライブラリは、本格的なプログラマーのために設計されたライブラリです。使い方が難しいため、大量生産はできない。そ れのどこがいいんだ？ただ、ライブラリを熟読して複雑なアプリケーションを作る人もいれば、そうでない人もいるのでしょうか？
2.開発者がアプリケーションでアニメーションを 作成するようにします。私と何の関係があるのですか？このアニメーションをGUIやEngineから独立して呼び出したり、アニメーションの呼び出しを何らかのボタンにリンクさせたりすることができる。
3)GUIが注目されるのは数人しかいない。あなたと、アナトリーと、あと誰か...。あとは、少しも深刻なレベルには達していない。
3.GUIが注目される人は少数派です。
私なら、そう断言はしませんね。しかも、guiライブラリの開発ではなく、guiアプリケーションの話だったんです。市場には、独自に開発したものを使っているもの、標準のライブラリを使っているもの、Anatolyのライブラリを使っているものなど、さまざまなものがあります。
1.そこがポイントで、GUIライブラリは本格的なプログラマーのために設計されています。使い方が難しいため、大量に普及させることはできない。そ れのどこがいいんだ？ライブラリを熟読して複雑なアプリケーションを作る人もいれば、そうでない人もいるのでは？
2.開発者がアプリケーションでアニメーションを作成するようにします。私と何の関係があるのですか？このアニメーションをGUIやEngineから独立して呼び出したり、アニメーションの呼び出しを何らかのボタンにリンクさせたりすることができる。
3)GUIが注目されるのは数人しかいない。あなたと、アナトリーと、あと誰か...。それ以外は、ちょっと深刻なレベルにも達していない。
ピーター 一番の問題は、プロジェクトの 位置づけにあると思うんです。
プログラミングの経験が豊富で、かつ、手を動かすことが好きな参加者だけが楽しめる内容になっています。
多いと思いますか？
いいですか、このデザインを批判しているのは、普段から「マニュアル」取引をしていない人ばかりなんです。せいぜい、ときどき。そして、彼らはあなたのプロジェクトを「マニュアル」のトレーダーとして見ていないので、プログラマーとして見ているのです。そして、当然のことながら、非常に怪しげな解決策をたくさん見つけることができるのです。
私の意見では、今の質問は、このニッチ（私の意見では、非常に狭いもの）を見つけることであるべきです：手を動かすことを好むプログラマ。
ハブラのようなどこかで「PythonのGUIビルダーを作る」という記事を見た気がするので、自分でコードを追加できるマルチプラットフォームGUIを見たことがある人がいるかもしれないと思ったのですが......。
コンストラクタを一から書くなら、むしろMQLを使ったほうがいい。
最近のGUIコンストラクター（「フォームにボタンをばらまく」もの）は、かなり技術的なもので、そこにMQLの要素をくっつけると、ファンタスティックに見えない。
中間形式（プロジェクト ファイルなど）では、ほとんどすべてのものが、レイアウトや要素間の関係を記述したXMLを持っています。
ターゲットプラットフォームのコード生成は、実際にはXSLTの変換であり、Web開発者だと思えば誰でもできることです :-)
例えば、EasyAndFast（https://www.mql5.com/ru/code/19703）は、オブジェクトベースで、必要なコンポーネントがすべて揃っているからです。(そして、このスレッドとは異なり、方法で開いて文書化された)、
、単にトランスレータを書きます。
gui-mqlのビルダーがいないのは、メガ・コンプレックスだからではなく、単に需要がないからです。