私のアプローチコアはエンジンです。 - ページ 140

新しいコメント
 
Реter Konow:

はい、その通りです。特定のGUIを再現し、そのGUIと連動するエンジンに必要なすべての情報。今はエンジンに直接インストールして、ビルダーが印刷するファイルからロードできるようにしています。

なんて複雑で分かりにくいんだろう。

必要なフォーム、ウィンドウ、エレメントを構築した後、#includeでプログラムに接続するためのmqhファイルを出力するだけにした方が、シャイタンボイラーのユーザーにとって楽ではないでしょうか？このファイルには、OnChartEvent()、OnTimer()、OnTick()などのリンク要素がすでに含まれています。あとは、必要なアクションをそれに規定するだけで、いずれにせよ、マークアップ言語の学習も必要です。そうでなければ、何も必要ありません。生成されたmqhファイルに必要なことをmqlで書けばいいだけです。

マークアップ言語を作り、それをなぜかユーザーが理解できない言語でつなぐという道を歩んできたのですね。このソリューションでは、mql言語ユーザーを製品に引きつけることはできません。

 

このスレッドの素晴らしさを見ると、人が最も心がけがちなのは「バカであり続けること」のようです。

 
Maxim Kuznetsov:
しかし、それはイベントにあるユーザーの編集やバインディングをすべて上書きしてしまうのでは？

GUIが変わるとすぐに - ユーザーはボタンを押して、新しいファイルを印刷します。エンジンは新しいカーネルをロードし、ユーザーアプリケーションは更新されたペアリングファイルを接続する必要があります。

この場合、一方のファイルを入れ替えるだけ（Conjunction Properties）、もう一方のファイルは再接続する必要があります。ただし、すでに書かれているコードを前のファイルからコピーすることは可能です。

重要なのは、GUIを決める前に接続ファイルを埋めてしまわないことです。新しいウィンドウが追加されたとしても、ほとんど影響はありません。古いウィンドウやエレメントを変更する場合、プログラムでもコードの作り直しが必要になることがあります。

 
Реter Konow:

これはすべてコンストラクタで行います。KIBのコードが書き込まれ、ファイルが再コンパイルされます。

以下は、コンストラクタの操作方法ですhttps://www.mql5.com/ru/blogs/post/717782

見てみると...ファイル名やフォルダ名で子供じみたミスをしたり、エディタを初めて開いたかのように作業したり......。

そして気づいたことは、これはまったくコンストラクタではないということです。ビジュアルコンストラクタがあるのでは...？

そして、このコンセプトをブレークスルーと呼ぶのですか？どこから、どこへ？

 
Artyom Trishkin:

なんて複雑で分かりにくいんだろう。

必要なフォーム、ウィンドウ、エレメントを構築した後、単にmqhファイルを出力して#includeでプログラムに接続するようにした方が、shaitan-boilerのユーザーにとって簡単ではないでしょうか？このファイルには、OnChartEvent()、OnTimer()、OnTick()などのリンク要素がすでに含まれています。あとは、必要なアクションをそれに規定するだけで、いずれにせよ、マークアップ言語の学習も必要です。そうでない場合は、生成されたmqhファイルに必要なことをmqlで記述すればよいのです。

ユーザーがなぜか理解できない言語を使って、マークアップと接続言語を作るという道を歩んできたんですね。このソリューションでは、mql言語ユーザーを製品に惹きつけることはできません。

ところで、そうなんです。

再コンパイルしても全く同じようになりました。もちろん、すぐに使えるMQHファイルを作ったことはなく、簡単なテキストファイルを書き、そこから初期化手順のテキストを基本モジュールに転送しているだけですが、考え方は同じです。

Peterさん、本当に、使い方を覚えなければならない設定の代わりに、既製の設定を持つMQHファイルが生成されれば、ユーザーの生活はかなり楽になりますね!

 
Artyom Trishkin:

これがあなたの言うブレークスルーという概念ですか？どこから、どこへ？

これは画期的なことです。「生地を切る」ボタン1つで既製のExpert Advisorを求める人々から（あるいは少なくとも2つのボタンで、もう1つは「巨大な生地を切る」）、ピーターの視覚部品の助けを借りて、取引を開始、同行、終了する半自動モードで取引する人々まで！このような人々にとって、この製品は非常に魅力的です。

そういう人が出てくれば、本当にブレイクスルーになると確信しています。

ただ、それが可能なのかどうか、疑問があります。人は元来怠惰なもので、ハンドトレード（セミオートマチックでも）には - 多くの経験が必要で、現地のビューモンドはどこからそれを得ているのでしょうか？

 
Georgiy Merts:

ところで、そうなんです。

これは、まさに私がリコンパイルするときの方法です。とはいえ、MQHファイルを用意するのではなく、プレーンテキストのファイルを書いて、そこから初期化手順のテキストをメインモジュールに転送しているのですが、考え方は同じです。

Peterさん、本当に、使い方を覚えなければならない設定の代わりに、既製の設定を持つMQHファイルが生成されれば、ユーザーの生活はより簡単になりますね。

どのような設定なのかがわからなかった。でも、できることはやりますよ。

 
Реter Konow:

より詳しく説明してください。

ドキュメントがないので、記憶（トラックの奥のほうのどこか）からリンクします :-)

インターフェース要素から「押された」「解放された」というメッセージをディスパッチする、スイッチを多数ネストした関数を持つファイルを生成するのです。そこでの出来事に対して、ユーザーがリアクションを入力する。
インターフェイスを変更・編集したのだから、このファイルはどうする？

例えば、パネルを2つのウィンドウに分割し、一方にはボタン、もう一方にはテーブルを表示させるために、ユーザーはどれだけの作業をしなければならないでしょうか（そうすれば、例えば、ユーザーがパネルを閉じても、画面上でうろうろせずに済みます）。
また、例えば、ある列を入れ替えた方がいい。レイアウトを作り、それを使い、より便利なものに外観を変えるという典型的なものです。

 
Реter Konow:

どのような設定なのかがわからない。でも、できることはやりますよ。

このアイデアは、すべてのフォーム、ウィンドウ、ビジュアル要素が構築された後、直接コンパイルするために、既製のMQLファイルが作成されるというものです。

私が今理解しているように、ユーザーはすべてのサイズ、座標、インデントを入力しなければなりません。これは非常に面倒で手間のかかる作業です。自動化されればいいのですが。その結果、再コンパイルが可能なMQHファイルができあがります。

 
Реter Konow:

どのような設定なのかがわからない。でも、できることはやりますよ。

OOPを学べば、できることだけでなく、それ以上のこと、つまり、今はまだ気づいていない創造性のための大きなスペースを、とっくの昔に実現できているはずです。素早く、効率的に、プロフェッショナルに。
しかし、あなたは何年も前から、常に大げさなエンジンでごまかし続けてきました。
そして、自分が書いたコードの量を誇れば、プログラミングにおける「インド人」である。これは侮辱ではなく、この定義を検索してみてください、まさにあなたのしていることにぴったりです。
1000行のコードを書いても、100行のコードを書いても、どちらも同じ動作のセットを行うことができます。しかし、肥大化したコードを変更したり補足したりするのは、肥大化していないコードよりもはるかに困難です。でも、あなたは自分が書いた行数を自慢して（ニコライの鼻を突いて）、それを一大プロジェクトと 呼ぶのが好きなんですね。まるで子供のように、なんということでしょう。

1...133134135136137138139140141142143144145146147...184
新しいコメント