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

 
Igor Makanu:

...

しかし、Windowsのイベントモデルの仕組みを知っていて、フォームデザイナを使ってコンパイラで作業した経験があれば、どこでもすべてが同じです

ZS: シャープを見るのは3回目なんですが、Delphiでは素晴らしい経験をしました。

Windowsのイベント モデルがどうなっているのか覚えていない。そして、長い間、コンパイラや設計者の経験を持っています。

作成したフォームをMTアプリケーションに接続して問題を解決したい。簡単って言ったじゃないですか。

 
Georgiy Merts:

見せるのではなく、その原理を明確に説明することによって。それが、「道路がおかしい」と反対されるのです。

しかも、それは作者にとってではなく、異議を唱える人々にとって「間違い」なのだ。ニワトリのような脳をしていて、どこでどんなモノを作ったか、どこで誰が参照したか、配列の各セルは何を意味しているか、どこから変更できて、どこからできないか...を覚えていないのです。反対派が激怒するのも無理はない。プログラム中の数千のオブジェクトや参照を簡単に覚えられるように記憶力を鍛える代わりに、愚かな人々はアクセス権を自分で切り、いくつかの区別、インターフェース、ポリモーフィックな関数を定義する...。ツァーリ政権下のように自分たちを拷問する、えー...。

記憶の冷静さなどという戯言は振り払う。このフォーラムの対話のスレッドが、2ページ分の深さまで追跡されていないことが時々観察されます。それに、彼らが私たちに伝えようとしているように、記憶が素晴らしく働くには、否定することが多すぎるのです。

 
Dmitry Fedoseev:

問題解決に協力してください。

  1. ボタンやチェックボックスを押したときのイベントをMT5に送信する必要があります。
  2. フォームのチェックボックスやボタンの状態をプログラムで変更する必要があります。
どうすればいいのか?
 

Windowsのフォームがある。起動し、動作する。ボタンやチェックボックスはクリック可能です。

MT5と接続するためのDLLが必要です。その方法を知っている人はいますか?

 
Реter Konow:

問題解決に協力してください。

  1. ボタンやチェックボックスを押したときのイベントをMT5に送信する必要があります。
  2. フォームのチェックボックスやボタンの状態をプログラムで変更する必要があります。
どうすればいいのか?

2.昨日、イゴールが例を示してくれた。Expert Advisorで、インポートしたDLLに含まれるクラスのメソッドを 呼び出す方法を示しています。つまり、チェックボックスの状態を変更する関数(メソッド)をc#で記述する必要があるのです。チェックボックスのプロパティを変更する方法、メソッドの名前を覚えていない、ドロップダウンリストで移動するのは簡単です、あなたはチェックボックスの名前を入力する必要があります、ドットを押してください...

1.どうだろう。たぶん、ないと思います。タイマーからDLL関数を呼び出して、チェックボックスの状態を見る必要があります。また、ボタンを押したようなイベントについては、配列を作成してそこにイベントを格納すればよいのではないでしょうか。しかし、視覚的に操作できる利点を考えれば、決して難しいことではありません。

 
Реter Konow:

C#をインストールしました。プロジェクトを開いた。フォームを作成し、2つのボタンと3つのチェックボックスを追加しました。

以下は、エディタでのコードです。

質問:なぜ1つのボタンに関数があり、2つ目のボタンとチェックボックスの関数はどこにあるのでしょうか?

こんなコードを発見。

MT5との連動に使うには?

2つ目のボタンが必要であることを示す必要があります。ダブルクリックをすると、コードが開き、関数が追加されます。その後、ボタンをフォームから削除すると、プロジェクトは エラーでコンパイルされます。コードは、あなたが書いたものではなく、いくつかのファイルから手動で削除する必要があります。

 
Dmitry Fedoseev:

2.昨日、イゴールさんが例を示してくれました。この例では、Expert AdvisorがインポートされたDLL内のクラスのメソッドを 呼び出す方法を示しています。つまり、チェックボックスの状態を変更する関数(メソッド)をc#で記述する必要があるのです。チェックボックスのプロパティを変更する方法、メソッドの名前を覚えていない、ドロップダウンリストで移動するのは簡単です、あなたはチェックボックスの名前を入力する必要があります、ドットを押してください...

1.どうだろう。たぶん、ないと思います。タイマーからDLL関数を呼び出して、チェックボックスの状態を見る必要があります。また、ボタンを押したようなイベントについては、配列を作成してそこにイベントを格納すればよいのではないでしょうか。しかし、コントロールを視覚的に扱えるという利点を考えれば、決して難しいことではありません。

オッケーです。

だから、必要なんです。

  1. DLLを作成する。
  2. フォームでウィドウアプリケーションに接続します。
  3. ボタンを押したときのイベントとチェックボックスを変換するメソッドをDLLに記述する。
  4. ウィドウアプリケーションでボタンやチェックボックスの状態を変更するメソッドを記述する.
  5. dllに共有メモリを作成する。MT5からアクセスしたときに、ボタンやチェックボックスの状態変化のフラグが立つようにする。そして、Windowsアプリケーションは共有メモリにアクセスしてフラグを読み出し、それを使って変更すべき1つまたは別のフォームエレメントの状態を知る。
  6. 関数呼び出しのフラグの読み取りやフィールドへのテキスト入力のために、MT5のタイマーからDLLへの循環的な参照を書き込む。

    エレメントが何百個もあったらどうする?

    共有メモリをどのように構成するか?

    フォーム内の要素の押下/解放の状態だけでなく、その色も変更する必要がある場合はどうでしょうか(例えば、ボタンの場合)。

    MT5からプログラム的にフォームの入力フィールドのテキストを変更する必要がある場合はどうすればよいでしょうか。


     
    Dmitry Fedoseev:

    ボタン押下などのイベントに関しては、配列を作ってそこに格納するのがベストでしょう。しかし、コントロールによるビジュアルワークの利点を考えれば、決して難しいことではありません。

    以前はもっとシンプルな方法でやっていたんです。

    1.ユーザーがフォーム上のボタンを押した - イベントハンドラOnClick()がクリックされ、Button1.Disableが作成された。

    2.その後、どのように交換を構成するかは、MT5次第です。私は、ボタンのクリックをOnTick()で問い合わせるのが好きです - とにかくティックに達するまで何もする必要はありません。


    しかし、私の例のポイントは、MT5のパネルの視覚化が2クリックで可能になったこと、ボタンハンドラが.dllで動作し、インターフェーススクリプトの一部がフォームに転送でき、同じテーブル、データ処理...であることです。何事も

    最も重要なことは、レンダリング開発の時間を節約できることです。フォームデザイナーの 助けを借りれば、すべてが数時間で完了します。)


    レタグ・コノウ

    DLLで共有メモリを作成する。そのため、MT5からのアクセスでは、ボタンやチェックボックスの状態変化のフラグが設定されます。アプリケーションは共有メモリにアクセスし、フラグを読み取り、1つまたは別のフォーム要素の状態を変更する必要があることを知ることができます。

    関数呼び出しのフラグの読み取りやフィールドへのテキスト入力のために、MT5のタイマーからDLLへの循環的な参照を書き込む。

      もし、数百もの要素があったら?

      共有メモリをどのように構成するか?

      また方向性が違うぞ!ソシャゲの2000年代から抜け出せ! ...なぜか2000年代が限界じゃない気がするけど ))))

      悪気はないのでしょうね?

       
      Igor Makanu:

      以前はもっとシンプルな方法でやっていたんです。

      1.ユーザーがフォーム上のボタンを押し、すぐにOnClick()ハンドラに入り、そこでButton1.Disableを作成する。

      2. その後、どのように交換するかはMT5次第です。私はボタンのクリックをOnTick()で問い合わせるのが好きです。とにかく、ティックに達しないまでは、タイマーに約300msの中立値を設定できます。


      しかし、私の例のポイントは、MT5のパネルの視覚化が2クリックで可能になったこと、ボタンハンドラが.dllで動作し、インターフェーススクリプトの一部がフォームに転送でき、同じテーブル、データ処理...であることです。何事も

      一番良いのはレンダリングの時間を短縮できることで、Forms Designerを使えばすべてが数時間で完了します;)


      また方向性が違うぞ!ソシャゲの2000年代から抜け出せ! ...2000年代が限界ではないと思うが ))))

      恨みっこなし、でしょうか?

      悪気はないのですが、要領を得ないのが残念です。

      あなたは、最も近い例を取り上げて、そこから外挿し、複雑さは増加しないと信じているのです。これは間違いです。

      あなたが挙げた最も単純な例でさえ、間違っているのです。なぜなら、作成されたフォームに加えて、DLLも作成する必要があるからです。そして、DLL内にTOTALメモリーを作成します。

      フォーム要素の数が増え、MT5上のプログラムの機能がより複雑になると、この対話は非常に忙しく複雑になります。

      これらすべてを実際に検証してみました。

       
      Реter Konow:

      OKです。

      だから、必要なんです。

      1. DLLを作成する。
      2. DLLとWindowsアプリケーションをフォームで接続します。
      3. ボタンやチェックボックスを押したときのイベントをDLLに変換するメソッドを書く。
      4. ウィドウアプリケーションでボタンやチェックボックスの状態を変更するメソッドを記述する.
      5. dllに共有メモリを作成する。MT5からアクセスしたときに、ボタンやチェックボックスの状態変化のフラグが立つようにする。そして、Windowsアプリケーションは共有メモリにアクセスしてフラグを読み出し、それを使って変更すべき1つまたは別のフォームエレメントの状態を知る。
      6. 関数呼び出しのフラグの読み取りやフィールドへのテキスト入力のために、MT5のタイマーからDLLへの循環的な参照を書き込む。

        エレメントが何百個もあったらどうする?

        共有メモリをどのように構成するか?

        フォーム内の要素の押下/解放の状態だけでなく、その色も変更する必要がある場合はどうでしょうか(例えば、ボタンの場合)。

        フォームの入力フィールドのテキストをプログラムでМТ5から変更する必要がある場合はどうすればよいでしょうか。


        イベントが正しく処理されれば、コントロールの数は問題ない。dllでは、オブジェクト名用の配列とイベントタイプ 用の配列の2つの配列を作成することができます。dllでは、2つのパラメータ、またイベント名とタイプを持つ関数を記述します。各イベントハンドラからこの関数を呼び出すと、イベントが配列に配置されます。別の方法 - EAタイマーからイベントを追跡するために、便利なまたはそれが判明したとして - 参照または何かとまた変数によって同じ配列 - 配列内のイベントの数を持つ。そのメソッドの呼び出しの後、配列はクリアされる。

        あるいは、1つの配列で作る方が簡単なのかもしれません。c#にはイベントオブジェクトがあるので、それを配列にすればいいのです。また、どうにかして、各イベントハンドラから勝手に関数を呼び出さないようにすることも可能なのかもしれませんね。しかし、そんなことはどうでもよくて、いずれにせよ、インターフェイスの機能やC#のあらゆるパワーに比べれば、取るに足らないことなのです。