OrderSendAsync()関数 - ページ 6 123456789 新しいコメント Yedelkin 2012.06.27 11:17 #51 Renat: 重要なのは、非同期リクエストは 実質的に「送信成功」というステータスを与えないという点である。 この関数が正常に終了すると、「クライアントから見て注文は正しく、ネットワークパイプに投げ込まれたので、OnTradeで応答を待ってください」というだけの意味になります。 すみません、ちょっとご無沙汰しています。 ただし、「Wait for reply onTrade」という言葉がありますが、これはリクエストがサーバーに届かなかった場合のことを指しています。 リクエストがサーバーに到達していない場合、この「見つからない」リクエストに関連する可能性のあるTradeイベントは生成されない。そうだろ？もしそうなら、OnTrade()でも適切な応答が得られませんね。そんな結論でよいのだろうか。 OrderSendAsync()関数が正常に終了した場合、リクエストがサーバーに到達しないことがあり、この場合OnTrade()で応答を待っても無駄である。 ? Yedelkin 2012.06.27 11:31 #52 sergeev: イェデルキン Sps!正常に送信された非同期リクエストは、簡単に履歴に残らないことが判明したのです。 いいえ。 説明してください。"いいえ "は、私の結論が間違っているのか、それともそれを裏付けるものなのか？ 最も、間違った結論ですが、Renatは先ほど、「リクエストがサーバーに届かなかったら、クライアント端末に表示されるチャンスは ない」と言いました。このロジックを続けるなら、もしリクエストがクライアント端末に表示される機会がなければ、ベース端末に入る機会もなく、したがって過去の注文のベースに入る機会もない。この推論が正しくないとすれば、どこに誤りがあり、それは何なのか。 Mykola Demko 2012.06.27 11:55 #53 Renat:重要なのは、非同期リクエストは実質的に「送信成功」というステータスを与えないということです。この機能が正常に終了すると、「クライアントから見て、注文は正しく見え、ネットワークパイプに投げ込まれたので、OnTradeで回答を待ってください」というだけの意味になります。近い将来、OnTradeが「リクエストがサーバーに 届かなかった」チェックを問題なく、また実際、他のタイプの実行制御と同様に、ユーザーによって整理できるように改善されることを期待しています。というのも、現在のOnTradeでは、どのような対応をしているのかが分からないため、そのような芸当はできないからです。 Renat Fatkhullin 2012.06.27 15:28 #54 Urain:近い将来、OnTradeが完成して、「リクエストがサーバーに届いて いない」チェックを、他の種類の実行制御と同様に、ユーザーが問題なく整理できるようになることを期待しています。なぜなら、現状のOnTradeでは、どのような対応をしているのかが分からないので、そのような芸当はできないからです。原理的には、リクエストを送信した後、5〜10秒以内にサーバーからリクエストが到達した旨の応答がない場合、「request failed by timeout」という仮想応答を追加することができます。これによって、OnTradeでの依頼のバツをキャッチすることができるようになります。しかし、これを行うには、パラメータを追加した関数をオーバーロードする必要があります。 Renat Fatkhullin 2012.06.27 15:30 #55 Yedelkin: リクエストがサーバーに到達していない場合、この「見つからない」リクエストに関連するTradeイベントは生成されない。そうだろ？ そうですね、納得です。上で説明したように仮想応答を追加すればいいのです。これにより、非同期処理の実行を制御することができるようになる。 Mykola Demko 2012.06.27 15:56 #56 Renat:原理的には、リクエストを送信した後、5〜10秒以内にサーバーからリクエストが到達した旨の応答がない場合に、「タイムアウトによりリクエストが失敗した」という仮想的な応答を追加することができるのです。これにより、OnTradeでの注文のバウンスをキャッチすることができます。しかし、そのためには、パラメータを追加した関数をオーバーロードする必要があります。怖いよ執行の制御を実現するためのパラメータを備えたOnTradeの改良が待たれるところです。1つのビルドで」つまり時系列的に次のビルドになるような音を出しているんですね。3つの注文を数ヶ月間ぶら下げ、タイムアウトを待っていたのに、「できる」と言うのは......。"しかし、オーバーロードが必要で..."OnTradeのリファインはやらないんですか？MQL5が間接的ではなく、直接的に実行制御を保証する機能を持つようになるまで、すべてのコードを書くのを先延ばしにしています。 Renat Fatkhullin 2012.06.27 16:01 #57 Urain:怖いよランタイムモニタリングを実装するためのパラメータを備えたOnTradeの改良を待っている人たちがいるのです。1つのビルドで」、つまり時系列的に次のビルドになるとおっしゃいましたが。何ヶ月も前から3つの注文を保留にしていたのですが、「可能です」と言われました。"しかし、オーバーロードが必要で..."OnTradeのリファインはしないんですか？次のビルドでやってみます。実は、制作中のタスクがたくさんあって、しかも夏休み期間中なので、いつもの開発ペースを維持するのは難しいんです。 Mykola Demko 2012.06.27 16:03 #58 Renat:忙しくても、次のビルドでできるようにしよう。仕事のタスクは本当に多く、しかもまだ休みの時期なので、夏場は通常の開発ペースを維持するのが難しいのです。ふぅ、安心しました :)本当に怖くて、お互いに話したり忘れたり、みんなが期待して待っている状況です :)長生きしたいものです :)) Aleksey 2012.06.27 19:13 #59 メタクオーツは、丈夫で軽く、汎用性の高い 端末を実現します。強くて軽い......彼らはすでにその作り方を知っている。しかし、ここにはもう一つ、継続性という課題があります。異なる取引プラットフォームや多くのブローカーが持つすべての「チョークポイント」を1つの端末でリンクさせる必要があるのです。これが問題なのだと思います。もう普遍的なMQ5は存在しないのです。PS はい OnTrade のパラメータが待っています。そして、私たち株式ブローカーにも。そして、非同期をうまく処理する方法が必要です。そうすると、（端末の）競合他社がいないようです。テスターだけでもかなりの価値があるのですが・・・。 Yedelkin 2012.06.28 05:17 #60 Renat: 原理的には、リクエストを送信した後、5〜10秒以内にサーバーからリクエストが到達した旨の応答がない場合に、「タイムアウトによりリクエストが失敗した」という仮想的な応答を追加することができるのです。 これにより、OnTradeのリクエストブレイクをキャッチすることができるようになります。しかし、そのためには、パラメータを追加して関数をオーバーロードする必要があります。 上で説明したように仮想応答を追加すればいいのです。これにより、非同期処理の実行を制御することができるようになる。 ありがとうございます、良い解決策ですね。少なくとも、私の問題は解決しました。待っている、でも押していない :) 123456789 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
重要なのは、非同期リクエストは 実質的に「送信成功」というステータスを与えないという点である。
この関数が正常に終了すると、「クライアントから見て注文は正しく、ネットワークパイプに投げ込まれたので、OnTradeで応答を待ってください」というだけの意味になります。
すみません、ちょっとご無沙汰しています。
ただし、「Wait for reply onTrade」という言葉がありますが、これはリクエストがサーバーに届かなかった場合のことを指しています。
リクエストがサーバーに到達していない場合、この「見つからない」リクエストに関連する可能性のあるTradeイベントは生成されない。そうだろ？もしそうなら、OnTrade()でも適切な応答が得られませんね。そんな結論でよいのだろうか。
OrderSendAsync()関数が正常に終了した場合、リクエストがサーバーに到達しないことがあり、この場合OnTrade()で応答を待っても無駄である。
?
sergeev:
Sps!正常に送信された非同期リクエストは、簡単に履歴に残らないことが判明したのです。
いいえ。
説明してください。"いいえ "は、私の結論が間違っているのか、それともそれを裏付けるものなのか？
最も、間違った結論ですが、Renatは先ほど、「リクエストがサーバーに届かなかったら、クライアント端末に表示されるチャンスは ない」と言いました。このロジックを続けるなら、もしリクエストがクライアント端末に表示される機会がなければ、ベース端末に入る機会もなく、したがって過去の注文のベースに入る機会もない。この推論が正しくないとすれば、どこに誤りがあり、それは何なのか。
重要なのは、非同期リクエストは実質的に「送信成功」というステータスを与えないということです。
この機能が正常に終了すると、「クライアントから見て、注文は正しく見え、ネットワークパイプに投げ込まれたので、OnTradeで回答を待ってください」というだけの意味になります。
近い将来、OnTradeが「リクエストがサーバーに 届かなかった」チェックを問題なく、また実際、他のタイプの実行制御と同様に、ユーザーによって整理できるように改善されることを期待しています。
というのも、現在のOnTradeでは、どのような対応をしているのかが分からないため、そのような芸当はできないからです。
近い将来、OnTradeが完成して、「リクエストがサーバーに届いて いない」チェックを、他の種類の実行制御と同様に、ユーザーが問題なく整理できるようになることを期待しています。
なぜなら、現状のOnTradeでは、どのような対応をしているのかが分からないので、そのような芸当はできないからです。
原理的には、リクエストを送信した後、5〜10秒以内にサーバーからリクエストが到達した旨の応答がない場合、「request failed by timeout」という仮想応答を追加することができます。
これによって、OnTradeでの依頼のバツをキャッチすることができるようになります。しかし、これを行うには、パラメータを追加した関数をオーバーロードする必要があります。
リクエストがサーバーに到達していない場合、この「見つからない」リクエストに関連するTradeイベントは生成されない。そうだろ？
そうですね、納得です。
上で説明したように仮想応答を追加すればいいのです。これにより、非同期処理の実行を制御することができるようになる。
原理的には、リクエストを送信した後、5〜10秒以内にサーバーからリクエストが到達した旨の応答がない場合に、「タイムアウトによりリクエストが失敗した」という仮想的な応答を追加することができるのです。
これにより、OnTradeでの注文のバウンスをキャッチすることができます。しかし、そのためには、パラメータを追加した関数をオーバーロードする必要があります。
怖いよ
執行の制御を実現するためのパラメータを備えたOnTradeの改良が待たれるところです。1つのビルドで」つまり時系列的に次のビルドになるような音を出しているんですね。
3つの注文を数ヶ月間ぶら下げ、タイムアウトを待っていたのに、「できる」と言うのは......。"しかし、オーバーロードが必要で..."
OnTradeのリファインはやらないんですか？
MQL5が間接的ではなく、直接的に実行制御を保証する機能を持つようになるまで、すべてのコードを書くのを先延ばしにしています。
怖いよ
ランタイムモニタリングを実装するためのパラメータを備えたOnTradeの改良を待っている人たちがいるのです。1つのビルドで」、つまり時系列的に次のビルドになるとおっしゃいましたが。
何ヶ月も前から3つの注文を保留にしていたのですが、「可能です」と言われました。"しかし、オーバーロードが必要で..."
OnTradeのリファインはしないんですか？
次のビルドでやってみます。
実は、制作中のタスクがたくさんあって、しかも夏休み期間中なので、いつもの開発ペースを維持するのは難しいんです。
忙しくても、次のビルドでできるようにしよう。
仕事のタスクは本当に多く、しかもまだ休みの時期なので、夏場は通常の開発ペースを維持するのが難しいのです。
ふぅ、安心しました :)
本当に怖くて、お互いに話したり忘れたり、みんなが期待して待っている状況です :)
長生きしたいものです :))
メタクオーツは、丈夫で軽く、汎用性の高い 端末を実現します。
強くて軽い......彼らはすでにその作り方を知っている。しかし、ここにはもう一つ、継続性という課題があります。異なる取引プラットフォームや多くのブローカーが持つすべての「チョークポイント」を1つの端末でリンクさせる必要があるのです。これが問題なのだと思います。もう普遍的なMQ5は存在しないのです。
PS はい OnTrade のパラメータが待っています。そして、私たち株式ブローカーにも。そして、非同期をうまく処理する方法が必要です。そうすると、（端末の）競合他社がいないようです。テスターだけでもかなりの価値があるのですが・・・。
原理的には、リクエストを送信した後、5〜10秒以内にサーバーからリクエストが到達した旨の応答がない場合に、「タイムアウトによりリクエストが失敗した」という仮想的な応答を追加することができるのです。
これにより、OnTradeのリクエストブレイクをキャッチすることができるようになります。しかし、そのためには、パラメータを追加して関数をオーバーロードする必要があります。
上で説明したように仮想応答を追加すればいいのです。これにより、非同期処理の実行を制御することができるようになる。