記事"DLLを使用せず、名前のつけられたパイプを使っての MetaTrader 5との通信"についてのディスカッション - ページ 2 1234567 新しいコメント Vladimir Gomonov 2012.10.17 19:11 #11 Reshetov:................一方ではdllを取り除くことができたが、他方では、やはりアプリケーションのために他のプログラミング言語の松葉杖が必要になる。提案された方法の欠点は、MQL以外の言語でアプリケーションを開発するプログラマーにしか適していないことである。 MQL5でもオウムを描くことができます。 コードが書かれた記事は こちらです。 Yury Reshetov 2012.10.17 19:14 #12 MetaDriver：MQL5でもオウムを描くことができる。 статья, с кодами 。興味のために、このトピックのタイトルくらいは読んだほうがいい もう違う。https://www.mql5.com/ru/forum/7806/page3。Renat: ただ、これはクライアントサポートであり、サーバー接続はターミナルでは作成できないことに注意してください。 Использование MQL5 для торговли на МТ4 www.mql5.com Подскажите, можно ли каким-нибудь образом извернуться, чтобы с помощью программ на MQL5 торговать у брокера, поддерживающего МТ4? Vladimir Gomonov 2012.10.17 19:24 #13 Reshetov:もう違う。https://www.mql5.com/ru/forum/7806/page3。 静かにやる。誰にも言わないで。シーッ...。 Yury Reshetov 2012.10.17 20:40 #14 MetaDriver: 目立たないようにするよ。誰にも言わないで。シーッ......。あ、あなた。開発者は一生懸命、クライアントにコネを作り、記事を書いた。なのにお前は何だ？すべてを投げ出し、C言語を学び、このすべてをオープンに正直に使う代わりに、あなたはひっそりと、地下深くでDLLを通してコネクターを追いかけている。いくら（指をさすのはやめておこう）餌を与えても、彼はまだターミナルでdllを使いたがる。普通のヒーローはいつも回り道をする © N. Korostylev Andrey Khatimlianskii 2012.10.17 22:43 #15 Reshetov:上記の記事の例に基づいてゲートウェイをMQL5で書いてください。そして純粋なMQLでクライアント・スクリプトを書けばいい。しかし、なぜこのような一方的な解決策を取らなければならないのか理解できない。C言語で自前のサーバーを書く人は、dllを接続するのは問題ないが、それ以外の機能は今のままでは不十分だろう。DLLのせいで作業が大幅に遅くなるのなら話は別だが（それはないだろう）。 Renat Fatkhullin 2012.10.18 10:16 #16 DLLを使わずにターミナルからサードパーティーのシステムに接続できるようにすることです。 サードパーティのアプリケーションを書く必要があるという不満は見当違いです。 Dmitriy Skub 2012.10.18 10:56 #17 Renat: トピックと記事の要点に注意してください。それは、DLLを使わずにターミナルからサードパーティーのシステムに接続できるようにすることです。課題は達成された。簡単に接続し、全二重のデータ交換ができるようになった。サードパーティーのアプリケーションを書かなければならないという不満は見当違いだ。 Renat、MT4にパイプを作る予定はいつですか？ Yury Reshetov 2012.10.18 11:17 #18 Renat: トピックと記事の要点に注意してください。それは、DLLを使わずにターミナルからサードパーティーシステムに接続できるようにすることです。課題は達成された。簡単に接続し、全二重のデータ交換ができるようになった。サードパーティーのアプリケーションを書かなければならないという不満は見当違いだ。 というのも、標準的な方法で、つまりサードパーティの松葉杖なしで、例えばMQLアプリケーション間の通信が提供されるとは宣言されていないからだ。"多くの開発者が同じ問題に直面している-安全でないDLLを使用せずに取引端末のサンドボックスに入るにはどうすればいいか"。ここにはクレームはないし、あってはならない。しかし一方で、MQLで書かれたアプリケーション間の通信を提供するという、アプリケーション計画で最も要求されるタスクは、この記事の 例では安全でないDLLを使用することで非常に効果的に解決されています。その記事では、文字列メッセージを介した通信を実装するには、MQL5でのプログラミングの知識と経験さえあれば十分だからだ（残りの作業、つまりWindows APIを介したサードパーティの松葉杖は、その記事の著者がすでに行い、既製のクラスとして掲載している）。 Renat Fatkhullin 2012.10.18 22:49 #19 しかし、外部システムとの通信の方が重要であり、応用が利く。そのためにセキュア・チャネルが開設されたのです。 また、実装全体が標準的なファイル操作の枠組みの中で行われていることにも注目してください。新しい関数を導入する必要はない。 Yury Reshetov 2012.10.18 23:25 #20 komposter:上記の記事の例に基づいて、MQL5で独自のゲートウェイを書いてみよう。理論的には可能だが、現実的には松葉杖になるだろうし、シンプレクスにさえなるだろう。最小限のコストでゲートウェイを作る方法について、いくつかの情報を見つけた。C++にはNamedPipeServerStream(String) というストリームのクラスがあることがわかった。これを呼び出すと、名前付きチャンネルが作成される。そして、IsConnected メソッドを呼び出して接続を待ち、2番目の名前付きチャンネルを作成することができる。別のクライアントが2つ目のチャネルに接続するのを待ち、CopyToAsync(Stream) メソッドを使用して1つ目のストリームから2つ目のストリームに情報をリダイレクトします。その後、サブプロセスを開始し、CopyToAsync(Stream) を 使用して、2つ目のストリームから1つ目のストリームに情報をリダイレクトします。こうすることで、両方の名前付きチャンネルが二重リンクされる。簡単そうに見えるが、私はC++の経験がない。Javaだったら、デバッグに30分はかかるだろう。今のところ、再設計に適した例を見つけた。http://msdn.microsoft.com/en-us/library/bb546085.aspx。 これをベースに全二重ゲートウェイを作ってみようと思う。うまくいったらどうしよう？ NamedPipeServerStream Constructor (String) (System.IO.Pipes) msdn.microsoft.com Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, Windows Vista SP2, Windows Server 2008 (Server Core Role not supported), Windows Server 2008 R2 (Server Core Role supported with SP1 or later; Itanium not supported) 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
................
一方ではdllを取り除くことができたが、他方では、やはりアプリケーションのために他のプログラミング言語の松葉杖が必要になる。
提案された方法の欠点は、MQL以外の言語でアプリケーションを開発するプログラマーにしか適していないことである。
興味のために、このトピックのタイトルくらいは読んだほうがいい
もう違う。https://www.mql5.com/ru/forum/7806/page3。
ただ、これはクライアントサポートであり、サーバー接続はターミナルでは作成できないことに注意してください。
もう違う。https://www.mql5.com/ru/forum/7806/page3。
目立たないようにするよ。誰にも言わないで。シーッ......。
あ、あなた。開発者は一生懸命、クライアントにコネを作り、記事を書いた。
なのにお前は何だ？すべてを投げ出し、C言語を学び、このすべてをオープンに正直に使う代わりに、あなたはひっそりと、地下深くでDLLを通してコネクターを追いかけている。
いくら（指をさすのはやめておこう）餌を与えても、彼はまだターミナルでdllを使いたがる。
普通のヒーローはいつも回り道をする © N. Korostylev
上記の記事の例に基づいてゲートウェイをMQL5で書いてください。そして純粋なMQLでクライアント・スクリプトを書けばいい。
しかし、なぜこのような一方的な解決策を取らなければならないのか理解できない。C言語で自前のサーバーを書く人は、dllを接続するのは問題ないが、それ以外の機能は今のままでは不十分だろう。DLLのせいで作業が大幅に遅くなるのなら話は別だが（それはないだろう）。
サードパーティのアプリケーションを書く必要があるという不満は見当違いです。
トピックと記事の要点に注意してください。それは、DLLを使わずにターミナルからサードパーティーのシステムに接続できるようにすることです。課題は達成された。簡単に接続し、全二重のデータ交換ができるようになった。サードパーティーのアプリケーションを書かなければならないという不満は見当違いだ。
トピックと記事の要点に注意してください。それは、DLLを使わずにターミナルからサードパーティーシステムに接続できるようにすることです。課題は達成された。簡単に接続し、全二重のデータ交換ができるようになった。サードパーティーのアプリケーションを書かなければならないという不満は見当違いだ。
というのも、標準的な方法で、つまりサードパーティの松葉杖なしで、例えばMQLアプリケーション間の通信が提供されるとは宣言されていないからだ。
"多くの開発者が同じ問題に直面している-安全でないDLLを使用せずに取引端末のサンドボックスに入るにはどうすればいいか"。
ここにはクレームはないし、あってはならない。
しかし一方で、MQLで書かれたアプリケーション間の通信を提供するという、アプリケーション計画で最も要求されるタスクは、この記事の 例では安全でないDLLを使用することで非常に効果的に解決されています。その記事では、文字列メッセージを介した通信を実装するには、MQL5でのプログラミングの知識と経験さえあれば十分だからだ（残りの作業、つまりWindows APIを介したサードパーティの松葉杖は、その記事の著者がすでに行い、既製のクラスとして掲載している）。
また、実装全体が標準的なファイル操作の枠組みの中で行われていることにも注目してください。新しい関数を導入する必要はない。
上記の記事の例に基づいて、MQL5で独自のゲートウェイを書いてみよう。
理論的には可能だが、現実的には松葉杖になるだろうし、シンプレクスにさえなるだろう。
最小限のコストでゲートウェイを作る方法について、いくつかの情報を見つけた。C++にはNamedPipeServerStream(String) というストリームのクラスがあることがわかった。
これを呼び出すと、名前付きチャンネルが作成される。そして、IsConnected メソッドを呼び出して接続を待ち、2番目の名前付きチャンネルを作成することができる。別のクライアントが2つ目のチャネルに接続するのを待ち、CopyToAsync(Stream) メソッドを使用して1つ目のストリームから2つ目のストリームに情報をリダイレクトします。その後、サブプロセスを開始し、CopyToAsync(Stream) を 使用して、2つ目のストリームから1つ目のストリームに情報をリダイレクトします。こうすることで、両方の名前付きチャンネルが二重リンクされる。
簡単そうに見えるが、私はC++の経験がない。Javaだったら、デバッグに30分はかかるだろう。
今のところ、再設計に適した例を見つけた。http://msdn.microsoft.com/en-us/library/bb546085.aspx。 これをベースに全二重ゲートウェイを作ってみようと思う。うまくいったらどうしよう？