私のアプローチコアはエンジンです。 - ページ 24 1...171819202122232425262728293031...184 新しいコメント Vitalii Ananev 2018.12.07 17:05 #231 Реter Konow:そうですね。 アプリケーションのGUIを担うエンジンは、コントロール（ボタン、入力フィールドなど）の仕組みを実行するだけです。 ボタン操作、チェックボックス、テキスト入力など、ユーザーのアクション。 直伝 は開発者のアプリケーションに渡される。 アプリケーションは、そのデータをフィールドやテーブルに転送することができます。 全ては簡単な接続ファイルを通して行われます。まあ、それならそれで別の問題なんですけどね。 Реter Konow 2018.12.07 18:24 #232 Yuriy Asaulenko:.NET-dllがMTに登場します。MTのGUIをC-sharpで作るのはもはや難しくなく、機能も充実しています。そ して、いずれにせよ、すべてのイベントはMT-ticksで行われるので、ボタンも同様です。まあ、分析ネジ、イミフ、ピーターにするよりもDLLに簡単。 一般的には、エンジンのピーター、誰もが有用であれば、それは唯一の市場セラー、ここでDLL nizizziです。まず、「全く苦労しない」というのは嘘ですね。C#で簡単にGUIを作ることができますが、それをMQL-applicationに接続するには？ そのような接続の例を示してください。これは少なくともキモオタのクレクレです。全てはDLLを通して行う必要があります。イベントの送信、イベントの受信... シャープのGUIと MTアプリケーションをDLLで接続する開発には、どれくらいの労力と時間がかかるのでしょうか？ 私のソリューションのシンプルさを前にして、誰がそれをするのか？ すでに接続用のインターフェイスは持っています。 接続の問題で30分（数ウィンドウの場合）。すべてがとてもシンプルです。DLLはありません。 つまり、これは、「死に物狂い」の発想なのです。 Yuriy Asaulenko 2018.12.07 18:29 #233 Реter Konow:まず、「大したことない」というのは嘘です。C#でGUIを作るのは簡単ですが、それをMQLアプリケーションに接続 するのは？ そのような接続の例を示してください。これは少なくともキモオタのクレクレです。すべてDLLを通して行わなければならない。イベントの送信、イベントの受信... DLLを使わずに、MTアプリケーションでシャープのGUIインターフェースを 開発するには、どれくらいの労力と時間がかかるのでしょうか？ 私のソリューションのシンプルさを前にして、誰がそれをするのか？接続インターフェースはすでに持っています。接続の問題で30分（複数ウィンドウの場合）。すべてがとてもシンプルです。DLLはありません。 つまり、これは、「死に物狂い」の発想なのです。すべてが同じです。合併症は全くありません。アプリケーションやDLLなど、どのような関数を呼び出すかに違いはありません。機能の呼び出しに 複雑さを感じることはありませんか？ Реter Konow 2018.12.07 18:35 #234 Yuriy Asaulenko:すべてが同じです。合併症はありません。アプリケーションとDLL、どちらの関数を呼び出しても違いはありません。機能呼び出しの 難しさを感じることはありませんか？いいえ、パラメータの値を同期させる必要があるメモリのことです。メモリは、ファイルか、DLL内の共有アプリケーションメモリ（または他の場所）のどちらかになければなりません。 しかし、これは本題ではありません。 THE GENERAL: シャープのGUIと接続するためのインターフェースは、開発者が独自 に設計する必要があります。 また、すでにすべての機能が動作しているのに、なぜそのようなことが必要なのでしょうか？ Yuriy Asaulenko 2018.12.07 18:37 #235 Реter Konow:いいえ、パラメータ値を同期させるべきメモリについてです。メモリは、ファイルまたはDLL内の共有アプリケーションメモリ（または他の場所）のいずれかでなければなりません。 しかし、これは本題ではありません。 THE GENERAL: シャープのGUIと接続するためのインターフェースは、開発者自身が考えなければ ならない。 また、すでにすべての機能が動作しているのに、なぜそのようなことが必要なのでしょうか？大げさだなあ）。 Реter Konow 2018.12.07 18:41 #236 Yuriy Asaulenko:大げさだなあ）。少しも。状況はわかっている。C++で書かれたDLLを介して、MTのアプリケーションとシャープのアプリケーションの間のインターフェイスを行ったことがあります。ひどい目にあった。ビジュアルスタジオとMTを同時に操作する必要があります。そして、アプリケーションを並列に実行すること。 しかし、肝心のアプリケーションパーツの相互作用のフォーマットが誰も開発して いないのです。だから、みんな一人で悩んでいるんです。 Yuriy Asaulenko 2018.12.07 18:45 #237 Реter Konow:一滴も落ちない。状況はわかっている。C++で書かれたDLLを介して、MTのアプリケーションとシャープのアプリケーションの間のインターフェイスを行ったことがあります。すごい面倒くさい。ビジュアルスタジオとMTを同時に操作する必要があります。そして、アプリケーションを並列に実行すること。 しかし、肝心のアプリケーションパーツの相互作用のフォーマットが誰も開発していないのです。それゆえ、誰もが自力で苦労することになる。DLLは、Windowsの標準的なツールです。DLLの相互運用性は、DOS時代から開発・利用されています。そこにはまったく問題がない。 Реter Konow 2018.12.07 18:50 #238 Yuriy Asaulenko:DLLは、Windowsの標準的なツールです。DLLとの相互運用は、DOS時代から長い間開発され、広く利用されてきました。そこにはまったく問題がない。シャープのDLLとの相互作用が発展してきた。また、ICLアプリケーションとシャープとのDLLを介したやりとりは、プログラマにとって個人的に面倒なことです。 共有メモリを整理し、フラグを読み取って関数を呼び出す必要がある。 その結果、DLLやファイル内にある共有メモリに延々と アクセスする必要がある。結局、シャープからDLL経由でMTにコールバックされることはないのです。 Yuriy Asaulenko 2018.12.07 18:56 #239 Реter Konow:シャープ側のDLLとのやりとりを工夫している。また、DLLを介したMKLアプリケーションとSharpeのやりとりは、プログラマーにとって個人的に面倒なことです。 共有メモリを整理し、フラグを読み取って関数を呼び出す必要がある。 その結果、DLLやファイル内にある共有メモリに延々と アクセスする必要がある。結局、シャープからDLL経由でMTにコールバックされることはないのです。MTにもコールバックはないんですね。すべてはMTのあらかじめ設定されたイベントによって行われ、それは一度きりである。 端末のイベントを DLLに送ることに変わりはなく、MT内、DLL内、どこで処理しても問題ありません。 Реter Konow 2018.12.07 18:59 #240 シャープからのメッセージをICLアプリケーションが常に確認することが迷惑にならないとしても、インタラクションフォーマットの開発は非常にボリュームのある作業 である。 このタスクの内容は以下の通りです。 1.共有メモリ組織を考え出す。 2.三者の相互作用を実装する。 3.三方（シャープ、DLL、MTアプリケーション）の同期テスト。 非常に時間がかかる。 私の場合、ユーザーがファイルを入手して記入する。そして、接続はうまくいく。 1...171819202122232425262728293031...184 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
そうですね。
アプリケーションのGUIを担うエンジンは、コントロール（ボタン、入力フィールドなど）の仕組みを実行するだけです。
ボタン操作、チェックボックス、テキスト入力など、ユーザーのアクション。 直伝 は開発者のアプリケーションに渡される。
アプリケーションは、そのデータをフィールドやテーブルに転送することができます。
全ては簡単な接続ファイルを通して行われます。
まあ、それならそれで別の問題なんですけどね。
.NET-dllがMTに登場します。MTのGUIをC-sharpで作るのはもはや難しくなく、機能も充実しています。そ して、いずれにせよ、すべてのイベントはMT-ticksで行われるので、ボタンも同様です。まあ、分析ネジ、イミフ、ピーターにするよりもDLLに簡単。
一般的には、エンジンのピーター、誰もが有用であれば、それは唯一の市場セラー、ここでDLL nizizziです。
まず、「全く苦労しない」というのは嘘ですね。C#で簡単にGUIを作ることができますが、それをMQL-applicationに接続するには？
そのような接続の例を示してください。これは少なくともキモオタのクレクレです。全てはDLLを通して行う必要があります。イベントの送信、イベントの受信...
シャープのGUIと MTアプリケーションをDLLで接続する開発には、どれくらいの労力と時間がかかるのでしょうか？
私のソリューションのシンプルさを前にして、誰がそれをするのか？ すでに接続用のインターフェイスは持っています。 接続の問題で30分（数ウィンドウの場合）。すべてがとてもシンプルです。DLLはありません。
つまり、これは、「死に物狂い」の発想なのです。
まず、「大したことない」というのは嘘です。C#でGUIを作るのは簡単ですが、それをMQLアプリケーションに接続 するのは？
そのような接続の例を示してください。これは少なくともキモオタのクレクレです。すべてDLLを通して行わなければならない。イベントの送信、イベントの受信...
DLLを使わずに、MTアプリケーションでシャープのGUIインターフェースを 開発するには、どれくらいの労力と時間がかかるのでしょうか？
私のソリューションのシンプルさを前にして、誰がそれをするのか？接続インターフェースはすでに持っています。接続の問題で30分（複数ウィンドウの場合）。すべてがとてもシンプルです。DLLはありません。
つまり、これは、「死に物狂い」の発想なのです。
すべてが同じです。合併症は全くありません。アプリケーションやDLLなど、どのような関数を呼び出すかに違いはありません。機能の呼び出しに 複雑さを感じることはありませんか？
すべてが同じです。合併症はありません。アプリケーションとDLL、どちらの関数を呼び出しても違いはありません。機能呼び出しの 難しさを感じることはありませんか？
いいえ、パラメータの値を同期させる必要があるメモリのことです。メモリは、ファイルか、DLL内の共有アプリケーションメモリ（または他の場所）のどちらかになければなりません。
しかし、これは本題ではありません。
THE GENERAL:
シャープのGUIと接続するためのインターフェースは、開発者が独自 に設計する必要があります。
また、すでにすべての機能が動作しているのに、なぜそのようなことが必要なのでしょうか？
いいえ、パラメータ値を同期させるべきメモリについてです。メモリは、ファイルまたはDLL内の共有アプリケーションメモリ（または他の場所）のいずれかでなければなりません。
しかし、これは本題ではありません。
THE GENERAL:
シャープのGUIと接続するためのインターフェースは、開発者自身が考えなければ ならない。
また、すでにすべての機能が動作しているのに、なぜそのようなことが必要なのでしょうか？
大げさだなあ）。
大げさだなあ）。
少しも。状況はわかっている。C++で書かれたDLLを介して、MTのアプリケーションとシャープのアプリケーションの間のインターフェイスを行ったことがあります。ひどい目にあった。ビジュアルスタジオとMTを同時に操作する必要があります。そして、アプリケーションを並列に実行すること。
しかし、肝心のアプリケーションパーツの相互作用のフォーマットが誰も開発して いないのです。だから、みんな一人で悩んでいるんです。
一滴も落ちない。状況はわかっている。C++で書かれたDLLを介して、MTのアプリケーションとシャープのアプリケーションの間のインターフェイスを行ったことがあります。すごい面倒くさい。ビジュアルスタジオとMTを同時に操作する必要があります。そして、アプリケーションを並列に実行すること。
しかし、肝心のアプリケーションパーツの相互作用のフォーマットが誰も開発していないのです。それゆえ、誰もが自力で苦労することになる。
DLLは、Windowsの標準的なツールです。DLLの相互運用性は、DOS時代から開発・利用されています。そこにはまったく問題がない。
DLLは、Windowsの標準的なツールです。DLLとの相互運用は、DOS時代から長い間開発され、広く利用されてきました。そこにはまったく問題がない。
シャープのDLLとの相互作用が発展してきた。また、ICLアプリケーションとシャープとのDLLを介したやりとりは、プログラマにとって個人的に面倒なことです。
共有メモリを整理し、フラグを読み取って関数を呼び出す必要がある。
その結果、DLLやファイル内にある共有メモリに延々と アクセスする必要がある。結局、シャープからDLL経由でMTにコールバックされることはないのです。
シャープ側のDLLとのやりとりを工夫している。また、DLLを介したMKLアプリケーションとSharpeのやりとりは、プログラマーにとって個人的に面倒なことです。
共有メモリを整理し、フラグを読み取って関数を呼び出す必要がある。
その結果、DLLやファイル内にある共有メモリに延々と アクセスする必要がある。結局、シャープからDLL経由でMTにコールバックされることはないのです。
MTにもコールバックはないんですね。すべてはMTのあらかじめ設定されたイベントによって行われ、それは一度きりである。
端末のイベントを DLLに送ることに変わりはなく、MT内、DLL内、どこで処理しても問題ありません。
シャープからのメッセージをICLアプリケーションが常に確認することが迷惑にならないとしても、インタラクションフォーマットの開発は非常にボリュームのある作業 である。
このタスクの内容は以下の通りです。
1.共有メモリ組織を考え出す。
2.三者の相互作用を実装する。
3.三方（シャープ、DLL、MTアプリケーション）の同期テスト。
非常に時間がかかる。
私の場合、ユーザーがファイルを入手して記入する。そして、接続はうまくいく。