MT5でOrderSendを正しく動作させる方法 - ページ 10 1...345678910111213 新しいコメント 削除済み 2016.12.21 23:06 #91 prostotrader: 使ってみてください。これは良い例です。しかし、ここで気になることがあります。OnTradeTransaction()が注文処理時のデータを返さない場合はどうすればよいですか?まあ、何らかの形で失われているのかもしれませんね。サーバーは送信したが、端末は受信していない。送信された注文の100%について必要な数のOnTradeTransaction()関数 コールが得られ、すべての取引報告が端末に到達することはどの程度保証されていますか(主にTRADE_TRANSACTION_REQUESTのトランザクションに興味があります)。なぜなら、もしこの応答がなければ(例えば接続が切れたために)フラグをクリアせず、すべてが立ち上がってしまうからです。 削除済み 2016.12.21 23:10 #92 fxsaber:確認はしていませんが、もしかしたらOrderSendの後、すべてのEAがOnTradeTransactionに対応するイベントを取得するのかもしれません。そうすれば、松葉杖なしで、同じシンボル上の複数のEAについて、すべてが解決されます。 確認しました!そういうものなんだ! prostotrader 2016.12.22 06:22 #93 Oleg Shenker:これは良い例です。しかし、ここで気になることがあります。OnTradeTransaction() が注文処理データを返さない場合はどうなりますか?まあ、何らかの形で失われているのかもしれませんね。サーバーは送信したが、端末は受信していない。送信された注文の100%について必要な数のOnTradeTransaction()関数 コールが得られ、すべての取引報告が端末に到達することはどの程度保証されていますか(主にTRADE_TRANSACTION_REQUESTのトランザクションに興味があります)。なぜなら、もしこの応答がなければ(例えば接続が切れたために)、私はフラグを削除せず、すべてはそのままにしておくからです。OnTradeTransactionのイベントが発生しないことが何度かありました。そこで、0.5秒周期のタイマーを使って注文の状態をチェックする関数を作りました。この実装はExpert Advisorの一般的なコードを複雑にしていますが、インターネット上で作業する場合、100%の保証はありません。すべてが規則正しく進むように。によって追加されました。ここでチェックすることを思いつきましたhttps://www.mql5.com/ru/blogs/post/557544 Отслеживание ордера, после команды OrderSendAsync 2015.04.29Mikhail Filimonovwww.mql5.com Отслеживание ордера, после команды OrderSendAsyncМихаил | 23 апреля, 2015В статье рассказывается принцип отслеживания ордера после команды OrderSendAsync, если нет события TradeTransaction... 削除済み 2016.12.27 16:15 #94 prostotrader:OnTradeTransaction イベントが発生しないことが何度かありました。そこで、周期0.5秒のタイマーを使ってオーダーの状態をチェックする関数を書きました。この実装はExpert Advisorの一般的なコードを複雑にしていますが、インターネット上で作業する場合、100%の保証はありません。すべてが規則正しく進むように。によって追加されました。ここでチェックすることを思いつきましたhttps://www.mql5.com/ru/blogs/post/557544取引ごとに特別な魔法のコードを作って、開かれた扉を突破しようとしているように思える。注文を一意に識別するための order_id が存在する。それとも、私が的外れなことを言っているのでしょうか? prostotrader 2016.12.28 01:04 #95 Oleg Shenker:この人は、トレードごとに特別な魔法のコードを作って、開かれた扉を突破しているような気がします。注文を一意に識別するために使用できる order_id がある。それとも、私が的外れなことを言っているのでしょうか?はい、order_idはありますが、残念ながらOnTradeTransactionに イベントが来ないことがあります。(個人的に何度か食べました)。そして、order_idをどこに "put "するか?によって追加されました。ここで、今日はサーバーの応答遅延が発生しました2016.12.28 14:04:56.442 (MXI-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...2016.12.28 14:04:56.443 (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается... 削除済み 2016.12.28 21:46 #96 prostotrader:はい、order_idはありますが、残念ながらOnTradeTransactionで イベントが来ないことがあります。(個人的に数回食べました)。order_idをどこに "stuff "するか?によって追加されました。ここで、今日はサーバーの応答遅延が発生しました2016.12.28 14:04:56.442 (MXI-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...2016.12.28 14:04:56.443 (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...この間、違う「バッフル」を持っていたんです。2016.12.23 15:04:02.865 TriArbTrader_8-4 (EURGBP,H1) 1111 DealSell 3 orders are sent.2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Retcode = 10009. Slippage = 1631.2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Position is closed in 59699 mksec.2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Retcode = 10009. Slippage = 1631.2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Position is closed in 59712 mksec.2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction GBPUSD Retcode = 10009. Slippage = 1379.2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction GBPUSD Position is closed in 127691 mksec.2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction All reposts are checked. Direction = 02016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction Unexpected transaction request.2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURGBP Retcode = 10009. Slippage = -40993.2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURGBP Position is closed in 1339448077 mksec.2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction All reposts are checked. Direction = -13つの命令が送られ、その記録がログにはっきりと残っている。その後、関数 OnTradeTransactions() TRADE_TRANSACTION_TYPE が4回呼び出されています。機能コードはチェックで始まる。void OnTradeTransaction(const MqlTradeTransaction& transaction, const MqlTradeRequest& request, const MqlTradeResult& results) { if(transaction.type == TRADE_TRANSACTION_REQUEST && request.action == TRADE_ACTION_DEAL) { if(request.magic == ExpertMagic) {つまり、専門家のハンコを押したTRADE_TRANSACTION_REQUIESTだけが、プリンターが立つ内部に入ることができる......というわけです。ヘルプデスクはまず、私が2つの同じEAを立ち上げていると説得し始めました(ログから判断すると、明らかに同じチャートに立っています)。そして、「お前は馬鹿だ、コードの誤りを直せ」と言われました。要するに、彼らに言わせれば、それはあり得ないことなのだ。しかし、ログを見ると、明らかに4回来ている。 How to work correctly フォルツァ執行上の問題点 OrderSendAsync 削除済み 2016.12.28 21:48 #97 prostotrader:はい、order_idはありますが、残念ながらOnTradeTransactionで イベントが来ないことがあります。(個人的に数回食べました)。order_idをどこに "stuff "するか?によって追加されました。ここで、今日はサーバーの応答遅延が発生しました。2016.12.28 14:04:56.442 (MXI-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...2016.12.28 14:04:56.443 (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...しかし、とにかく、なぜティッカーで注文を検索できないのか、いまだに理解できない。送った注文のうち、どれがTradeTransactionに来なかったかを確認するのはとても簡単です。そして、このチケットでの注文の状況を履歴で見るだけです。しかし、注文履歴にはステータスが「FILLED」の注文のみが表示されます。 prostotrader 2016.12.29 15:04 #98 Oleg Shenker:それにしても、なぜティッカーで注文を検索できないのかが不明です。結局、どの注文がTradeTransactionに来なかったかを確認するのは簡単だ。そして、このテロップのある注文の状況を履歴で見るだけです。とはいえ、個人的に試したところ、注文履歴ではステータスが「FILLED」の注文しかありませんでしたが。はい、注文が履歴に残らない場合があるためです(保留注文など)。追加そして、あなたは間違ったコードを持っています 削除済み 2016.12.29 19:04 #99 prostotrader:はい、注文が履歴に残らない場合があるためです(保留注文など)。によって追加されました。そして、あなたは間違ったコードを持っていますそこはどうしたんですか?2行のコードでどれだけの間違いを犯すことができるか。 prostotrader 2016.12.29 21:00 #100 Oleg Shenker:そこで何が問題なのか?2行のコードでどれだけの間違いがあるか。2つではなく、1つです :)if(transaction.type == TRADE_TRANSACTION_REQUEST && request.action == TRADE_ACTION_DEAL)TRADE_TRANSACTION_REQUESTは、OrderSendAsymcを 使用してオーダーチケットを取得する際に必要です。 1...345678910111213 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
使ってみてください。
これは良い例です。しかし、ここで気になることがあります。OnTradeTransaction()が注文処理時のデータを返さない場合はどうすればよいですか?まあ、何らかの形で失われているのかもしれませんね。サーバーは送信したが、端末は受信していない。送信された注文の100%について必要な数のOnTradeTransaction()関数 コールが得られ、すべての取引報告が端末に到達することはどの程度保証されていますか(主にTRADE_TRANSACTION_REQUESTのトランザクションに興味があります)。
なぜなら、もしこの応答がなければ(例えば接続が切れたために)フラグをクリアせず、すべてが立ち上がってしまうからです。
確認はしていませんが、もしかしたらOrderSendの後、すべてのEAがOnTradeTransactionに対応するイベントを取得するのかもしれません。
そうすれば、松葉杖なしで、同じシンボル上の複数のEAについて、すべてが解決されます。
これは良い例です。しかし、ここで気になることがあります。OnTradeTransaction() が注文処理データを返さない場合はどうなりますか?まあ、何らかの形で失われているのかもしれませんね。サーバーは送信したが、端末は受信していない。送信された注文の100%について必要な数のOnTradeTransaction()関数 コールが得られ、すべての取引報告が端末に到達することはどの程度保証されていますか(主にTRADE_TRANSACTION_REQUESTのトランザクションに興味があります)。
なぜなら、もしこの応答がなければ(例えば接続が切れたために)、私はフラグを削除せず、すべてはそのままにしておくからです。
OnTradeTransactionのイベントが発生しないことが何度かありました。
そこで、0.5秒周期のタイマーを使って注文の状態をチェックする関数を作りました。
この実装はExpert Advisorの一般的なコードを複雑にしていますが、インターネット上で作業する場合、100%の保証はありません。
すべてが規則正しく進むように。
によって追加されました。
ここでチェックすることを思いつきました
https://www.mql5.com/ru/blogs/post/557544
OnTradeTransaction イベントが発生しないことが何度かありました。
そこで、周期0.5秒のタイマーを使ってオーダーの状態をチェックする関数を書きました。
この実装はExpert Advisorの一般的なコードを複雑にしていますが、インターネット上で作業する場合、100%の保証はありません。
すべてが規則正しく進むように。
によって追加されました。
ここでチェックすることを思いつきました
https://www.mql5.com/ru/blogs/post/557544
取引ごとに特別な魔法のコードを作って、開かれた扉を突破しようとしているように思える。注文を一意に識別するための order_id が存在する。
それとも、私が的外れなことを言っているのでしょうか?
この人は、トレードごとに特別な魔法のコードを作って、開かれた扉を突破しているような気がします。注文を一意に識別するために使用できる order_id がある。
それとも、私が的外れなことを言っているのでしょうか?
はい、order_idはありますが、残念ながらOnTradeTransactionに イベントが来ないことがあります。
(個人的に何度か食べました)。
そして、order_idをどこに "put "するか?
によって追加されました。
ここで、今日はサーバーの応答遅延が発生しました
2016.12.28 14:04:56.443 (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...
はい、order_idはありますが、残念ながらOnTradeTransactionで イベントが来ないことがあります。
(個人的に数回食べました)。
order_idをどこに "stuff "するか?
によって追加されました。
ここで、今日はサーバーの応答遅延が発生しました
2016.12.28 14:04:56.443 (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...
この間、違う「バッフル」を持っていたんです。
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Retcode = 10009. Slippage = 1631.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Position is closed in 59699 mksec.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Retcode = 10009. Slippage = 1631.
2016.12.23 15:04:02.924 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURUSD Position is closed in 59712 mksec.
2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction GBPUSD Retcode = 10009. Slippage = 1379.
2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction GBPUSD Position is closed in 127691 mksec.
2016.12.23 15:04:02.992 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction All reposts are checked. Direction = 0
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction Unexpected transaction request.
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURGBP Retcode = 10009. Slippage = -40993.
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction EURGBP Position is closed in 1339448077 mksec.
2016.12.23 15:04:02.993 TriArbTrader_8-4 (EURGBP,H1) 1111 OnTradeTransaction All reposts are checked. Direction = -1
3つの命令が送られ、その記録がログにはっきりと残っている。その後、関数 OnTradeTransactions() TRADE_TRANSACTION_TYPE が4回呼び出されています。
機能コードはチェックで始まる。
const MqlTradeRequest& request,
const MqlTradeResult& results)
{
if(transaction.type == TRADE_TRANSACTION_REQUEST && request.action == TRADE_ACTION_DEAL)
{
if(request.magic == ExpertMagic)
{
つまり、専門家のハンコを押したTRADE_TRANSACTION_REQUIESTだけが、プリンターが立つ内部に入ることができる......というわけです。
ヘルプデスクはまず、私が2つの同じEAを立ち上げていると説得し始めました(ログから判断すると、明らかに同じチャートに立っています)。そして、「お前は馬鹿だ、コードの誤りを直せ」と言われました。
要するに、彼らに言わせれば、それはあり得ないことなのだ。しかし、ログを見ると、明らかに4回来ている。
はい、order_idはありますが、残念ながらOnTradeTransactionで イベントが来ないことがあります。
(個人的に数回食べました)。
order_idをどこに "stuff "するか?
によって追加されました。
ここで、今日はサーバーの応答遅延が発生しました。
2016.12.28 14:04:56.443 (GOLD-3.17,M1) CheckOrders: Задержка ответа сервера. Ожидание продолжается...
しかし、とにかく、なぜティッカーで注文を検索できないのか、いまだに理解できない。送った注文のうち、どれがTradeTransactionに来なかったかを確認するのはとても簡単です。そして、このチケットでの注文の状況を履歴で見るだけです。
しかし、注文履歴にはステータスが「FILLED」の注文のみが表示されます。
それにしても、なぜティッカーで注文を検索できないのかが不明です。結局、どの注文がTradeTransactionに来なかったかを確認するのは簡単だ。そして、このテロップのある注文の状況を履歴で見るだけです。
とはいえ、個人的に試したところ、注文履歴ではステータスが「FILLED」の注文しかありませんでしたが。
はい、注文が履歴に残らない場合があるためです(保留注文など)。
追加
そして、あなたは間違ったコードを持っています
はい、注文が履歴に残らない場合があるためです(保留注文など)。
によって追加されました。
そして、あなたは間違ったコードを持っています
そこはどうしたんですか?2行のコードでどれだけの間違いを犯すことができるか。
そこで何が問題なのか?2行のコードでどれだけの間違いがあるか。
2つではなく、1つです :)
TRADE_TRANSACTION_REQUESTは、OrderSendAsymcを 使用してオーダーチケットを取得する際に必要です。