OnTradeTransaction処理 - ページ 2 12345678910 新しいコメント Ilya Rebenok 2019.02.07 21:16 #11 fxsaber:テイクとストップの注文を同時に2つまで出すことはできますか?そうです、最初にエントリーしてTPとストップオーダーを 設定したのです。そして、しばらくしてから、さらにエントリーを追加し、TPとストップを設定することもあります。 JRandomTrader 2019.02.07 22:55 #12 紛失した場合に備えて、発注した注文、最後に計上した取引のチケット、最後に状態を記録(変更)した時刻を記憶し、イニシエーション時だけでなく定期的に、注文一覧を同期して未計上の取引がないか確認しています。 ランダムにイベントが発生するのが普通で、注文と履歴の両方で(一時的な)注文がないことは珍しくなく、取引が発生する前と後の両方で発生することがあります。 ネッティング時のポジションは、最初の注文のチケットを受け取り、その後の取引(変更)時に、それがクローズされる(すなわち0.0になる)までの間、それを保存する。 まあ、注文の量によっては、何回か取引が発生することもあるんですけどね。 prostotrader 2019.02.08 00:09 #13 Илья Ребенок: あなたの経験やアイデアをお聞かせください。最初からちゃんとしてないじゃん。 なぜ、マジコンや各種チェックをするのか? 注文のチケットは、一意の識別子です。 同期注文を送信した場合、機能の結果としてチケットを受け取ることができます。 非同期注文を送信した場合、OnTradeTransactionで チケットを取得します。 追加 そして、ここhttps://www.mql5.com/ru/forum/67298/page2#comment_2089220。 は、順序を確認するのに適した関数です。 ФОРТС: В помощь начинающим 2015.11.25www.mql5.com Установка отложенного ордера командой OrderSend(). fxsaber 2019.02.08 07:40 #14 Илья Ребенок:そうです、最初にエントリーしてTPとストップオーダーを 設定したのです。そして、しばらくしてから、上乗せして、またTPとストップ注文を出せばいいのです。TP/SLを要求する指値注文は、部分的に約定する可能性があります。同時に、リミットオーダー形式のTPも同様に執行されます。例えば、TPを1/3量執行した場合、SLも同じ量だけ減少させる必要があります。 全体として、すべてのトリックをキャッチするためのかなり不快なロジックです。 このタスクはOnTradeに実装する必要があります。実装は難しくないはずです。 Ilya Rebenok 2019.02.08 09:36 #15 prostotrader:最初からやり方が間違ってる。 なぜ、マジコンや各種チェックをするのか? 注文のチケットは、一意の識別子です。 同期送信の場合は、関数の結果としてチケットを受信します。 非同期注文を送信した場合、OnTradeTransactionで チケットを取得します。 追加 そして、ここhttps://www.mql5.com/ru/forum/67298/page2#comment_2089220 は、順序を確認するのに適した関数です。 ありがとうございます、読ませていただきます。JRandomTrader。イベントの紛失に備えて、発注、最後に計上した取引のチケット、最後に状態を入力(変更)した時刻を記憶し、発生時と同様に定期的に発注リストを同期して、未記録の取引がないか確認しています。 ランダムに発生するのが普通で、注文と履歴の両方に(一時的な)秩序がないことは珍しくなく、取引が発生する前と後の両方で発生する可能性があります。 ネッティング時のポジションは、最初の注文のチケットを取得し、その後の取引(変更)では、クローズするまで(つまり0.0になるまで)それを保存する。 まあ、注文の量によっては、複数の取引が発生することもあるんですけどね。ロボットの目的の1つは、ローカル依存をなくすことでした。つまり、端末やPCの変数に縛られることなく、市場からのデータのみを受け取ることができるのだ。つまり、急を要する場合には、私が別のPCに切り替えれば、ロボットがすべて拾ってくれるのです。 今、また面白いバグを発見しました。同じTRADE_TRANSACTION_DEAL_ADDトランザクションを2つ受信しました。すみません、これは一体何なんでしょう(笑)結局、ロボットは1つの取引に2つのストップをかけてしまった。 2019.02.08 10:55:29 [INFO]: ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD。 貿易取引取引追加 シンボル:RTS-3.19 ディールチケット:12674810 ディールタイプ:DEAL_TYPE_BUY 注文書:82646001 オーダータイプ:ORDER_TYPE_BUY 注文状態:ORDER_STATE_STARTED オーダー時間タイプ:ORDER_TIME_GTC 注文有効期限:1970.01.01 00:00 価格:119700 価格トリガー:0 ストップロス:0 テイクプロフィット:0 巻数:1巻 ポジション:82646001 ポジション別:0 2019.02.08 10:55:32 [INFO]: ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD。 貿易取引取引追加 シンボル:RTS-3.19 ディールチケット:12674810 ディールタイプ:DEAL_TYPE_BUY 注文書:82646001 オーダータイプ:ORDER_TYPE_BUY 注文状態:ORDER_STATE_STARTED オーダー時間タイプ:ORDER_TIME_GTC 注文有効期限:1970.01.01 00:00 価格:119700 価格トリガー:0 ストップロス:0 テイクプロフィット:0 巻数:1巻 ポジション:82646001 ポジション別:0 OnTradeTransaction processing Ilya Baranov 2019.02.08 09:39 #16 取引イベント(TRADE_TRANSACTION_DEAL_ADD)は、定期的に数回発生します。 幸いなことに、最新のものだけが繰り返されます(少なくとも私は古いものをキャッチしていません)。 フィルタリングは、トランザクションチケットが前回のチケットと同じかどうかを確認することで十分です。 prostotrader 2019.02.08 10:06 #17 Ilya Baranov:取引イベント(TRADE_TRANSACTION_DEAL_ADD)は、定期的に数回発生します。 幸いなことに、最新のものだけが繰り返されます(少なくとも私は古いものをキャッチしていません)。 フィルタリングするには、トランザクションチケットが前回のチケットと同じかどうかを確認すれば十分です。複数回ではなく、現在ターミナルで動作しているEAの数で判断します。 そのため、各EAが独自に注文を処理する必要があります case TRADE_TRANSACTION_DEAL_ADD: if((BuyOrder.ticket > 0) && (trans.order == BuyOrder.ticket)) // Buy order { //Сделка этого советника } break; Ilya Baranov 2019.02.08 10:14 #18 prostotrader:複数回ではなく、現在ターミナルで動作しているEAの数で判断します。 そのため、各EAが独自にオーダーを処理する必要がある あなたのコードは、それがこのEAの取引であったという事実に対して保護します。 私と TS は、TRADE_TRANSACTION_DEAL_ADD タイプの OnTradeTransaction が1 つの取引で複数回呼び出された場合、つまりMqlTradeTransaction の 他のフィールドにまったく同じデータが含まれる場合について述べています。 あなたの場合、処理コードが何度も実行される可能性があるということです。 おそらく、すべてのブローカーがそうであるとは限りません。しかし、それは私が働いていたすべての証券会社で定期的に起こっていることです。 prostotrader 2019.02.08 10:23 #19 Ilya Baranov:あなたのコードは、それがこのEAの取引であったという事実に対して保護されています。 私やTSは、TRADE_TRANSACTION_DEAL_ADD 型のOnTradeTransactionが一つの取引で複数回呼ば れる場合、つまりMqlTradeTransactionの 他のフィールドが全く同じデータを持っている場合について話しているのです。 あなたの場合、処理コードが何度も実行される可能性があるということです。 おそらく、すべてのブローカーがそうであるとは限りません。しかし、それは私が担当したすべてのブローカーで定期的に起こることです。オトクリバシカでリアルで取引し、デモでテストしていますが、複数のトリガーを持っているわけではありません。 TRADE_TRANSACTION_DEAL_ADDの コードを投稿してください。 Ilya Rebenok 2019.02.08 10:31 #20 Ilya Baranov:取引イベント(TRADE_TRANSACTION_DEAL_ADD)は、定期的に数回発生します。 幸いなことに、最新のものだけが繰り返されます(少なくとも私は古いものをキャッチしていません)。 フィルタリングするには、トランザクションチケットが前回のチケットと同じかどうかを確認すれば十分です。はい、ありがとうございますただ、見た後にそうしました。 当初の問題としては、注文を削除して履歴に追加するというトランザクションをポンピングする時間を持つために伝票を貼ったのです。観察された。 この点でのプラットフォームの不完全さは、非常に悲しいことです。束ねるべきものが、別々のものを作る。 プロストトレーダー数回ではなく、現在ターミナルで動作しているEAの数で。 そのため、各EAが独自に注文を処理する必要がある この場合、やはり依頼主からの注文のチケットをどこかに保存して、取引からのチケットと比較する必要があります。そして、ローカル 変数のストレージをすべて取り除き、マーケット/ターミナルからのみ情報を取得し、ローカルインフラのリスクを平準化したいだけです。 12345678910 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
テイクとストップの注文を同時に2つまで出すことはできますか?
そうです、最初にエントリーしてTPとストップオーダーを 設定したのです。そして、しばらくしてから、さらにエントリーを追加し、TPとストップを設定することもあります。
紛失した場合に備えて、発注した注文、最後に計上した取引のチケット、最後に状態を記録(変更)した時刻を記憶し、イニシエーション時だけでなく定期的に、注文一覧を同期して未計上の取引がないか確認しています。
ランダムにイベントが発生するのが普通で、注文と履歴の両方で(一時的な)注文がないことは珍しくなく、取引が発生する前と後の両方で発生することがあります。
ネッティング時のポジションは、最初の注文のチケットを受け取り、その後の取引(変更)時に、それがクローズされる(すなわち0.0になる)までの間、それを保存する。
まあ、注文の量によっては、何回か取引が発生することもあるんですけどね。あなたの経験やアイデアをお聞かせください。
最初からちゃんとしてないじゃん。
なぜ、マジコンや各種チェックをするのか?
注文のチケットは、一意の識別子です。
同期注文を送信した場合、機能の結果としてチケットを受け取ることができます。
非同期注文を送信した場合、OnTradeTransactionで チケットを取得します。
追加
そして、ここhttps://www.mql5.com/ru/forum/67298/page2#comment_2089220。
は、順序を確認するのに適した関数です。
そうです、最初にエントリーしてTPとストップオーダーを 設定したのです。そして、しばらくしてから、上乗せして、またTPとストップ注文を出せばいいのです。
TP/SLを要求する指値注文は、部分的に約定する可能性があります。同時に、リミットオーダー形式のTPも同様に執行されます。例えば、TPを1/3量執行した場合、SLも同じ量だけ減少させる必要があります。
全体として、すべてのトリックをキャッチするためのかなり不快なロジックです。
このタスクはOnTradeに実装する必要があります。実装は難しくないはずです。
最初からやり方が間違ってる。
なぜ、マジコンや各種チェックをするのか?
注文のチケットは、一意の識別子です。
同期送信の場合は、関数の結果としてチケットを受信します。
非同期注文を送信した場合、OnTradeTransactionで チケットを取得します。
追加
そして、ここhttps://www.mql5.com/ru/forum/67298/page2#comment_2089220
は、順序を確認するのに適した関数です。
イベントの紛失に備えて、発注、最後に計上した取引のチケット、最後に状態を入力(変更)した時刻を記憶し、発生時と同様に定期的に発注リストを同期して、未記録の取引がないか確認しています。
ランダムに発生するのが普通で、注文と履歴の両方に(一時的な)秩序がないことは珍しくなく、取引が発生する前と後の両方で発生する可能性があります。
ネッティング時のポジションは、最初の注文のチケットを取得し、その後の取引(変更)では、クローズするまで(つまり0.0になるまで)それを保存する。
まあ、注文の量によっては、複数の取引が発生することもあるんですけどね。ロボットの目的の1つは、ローカル依存をなくすことでした。つまり、端末やPCの変数に縛られることなく、市場からのデータのみを受け取ることができるのだ。つまり、急を要する場合には、私が別のPCに切り替えれば、ロボットがすべて拾ってくれるのです。
今、また面白いバグを発見しました。同じTRADE_TRANSACTION_DEAL_ADDトランザクションを2つ受信しました。すみません、これは一体何なんでしょう(笑)結局、ロボットは1つの取引に2つのストップをかけてしまった。
2019.02.08 10:55:29 [INFO]: ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD。
貿易取引取引追加
シンボル:RTS-3.19
ディールチケット:12674810
ディールタイプ:DEAL_TYPE_BUY
注文書:82646001
オーダータイプ:ORDER_TYPE_BUY
注文状態:ORDER_STATE_STARTED
オーダー時間タイプ:ORDER_TIME_GTC
注文有効期限:1970.01.01 00:00
価格:119700
価格トリガー:0
ストップロス:0
テイクプロフィット:0
巻数:1巻
ポジション:82646001
ポジション別:0
2019.02.08 10:55:32 [INFO]: ( PChBreak_RTS-3.19_22 ) TRADE_TRANSACTION_DEAL_ADD。
貿易取引取引追加
シンボル:RTS-3.19
ディールチケット:12674810
ディールタイプ:DEAL_TYPE_BUY
注文書:82646001
オーダータイプ:ORDER_TYPE_BUY
注文状態:ORDER_STATE_STARTED
オーダー時間タイプ:ORDER_TIME_GTC
注文有効期限:1970.01.01 00:00
価格:119700
価格トリガー:0
ストップロス:0
テイクプロフィット:0
巻数:1巻
ポジション:82646001
ポジション別:0
取引イベント(TRADE_TRANSACTION_DEAL_ADD)は、定期的に数回発生します。
幸いなことに、最新のものだけが繰り返されます(少なくとも私は古いものをキャッチしていません)。
フィルタリングは、トランザクションチケットが前回のチケットと同じかどうかを確認することで十分です。
取引イベント(TRADE_TRANSACTION_DEAL_ADD)は、定期的に数回発生します。
幸いなことに、最新のものだけが繰り返されます(少なくとも私は古いものをキャッチしていません)。
フィルタリングするには、トランザクションチケットが前回のチケットと同じかどうかを確認すれば十分です。
複数回ではなく、現在ターミナルで動作しているEAの数で判断します。
そのため、各EAが独自に注文を処理する必要があります
複数回ではなく、現在ターミナルで動作しているEAの数で判断します。
そのため、各EAが独自にオーダーを処理する必要がある
あなたのコードは、それがこのEAの取引であったという事実に対して保護します。
私と TS は、TRADE_TRANSACTION_DEAL_ADD タイプの OnTradeTransaction が1 つの取引で複数回呼び出された場合、つまりMqlTradeTransaction の 他のフィールドにまったく同じデータが含まれる場合について述べています。
あなたの場合、処理コードが何度も実行される可能性があるということです。
おそらく、すべてのブローカーがそうであるとは限りません。しかし、それは私が働いていたすべての証券会社で定期的に起こっていることです。
あなたのコードは、それがこのEAの取引であったという事実に対して保護されています。
私やTSは、TRADE_TRANSACTION_DEAL_ADD 型のOnTradeTransactionが一つの取引で複数回呼ば れる場合、つまりMqlTradeTransactionの 他のフィールドが全く同じデータを持っている場合について話しているのです。
あなたの場合、処理コードが何度も実行される可能性があるということです。
おそらく、すべてのブローカーがそうであるとは限りません。しかし、それは私が担当したすべてのブローカーで定期的に起こることです。
オトクリバシカでリアルで取引し、デモでテストしていますが、複数のトリガーを持っているわけではありません。
TRADE_TRANSACTION_DEAL_ADDの コードを投稿してください。
取引イベント(TRADE_TRANSACTION_DEAL_ADD)は、定期的に数回発生します。
幸いなことに、最新のものだけが繰り返されます(少なくとも私は古いものをキャッチしていません)。
フィルタリングするには、トランザクションチケットが前回のチケットと同じかどうかを確認すれば十分です。
はい、ありがとうございますただ、見た後にそうしました。
当初の問題としては、注文を削除して履歴に追加するというトランザクションをポンピングする時間を持つために伝票を貼ったのです。観察された。
この点でのプラットフォームの不完全さは、非常に悲しいことです。束ねるべきものが、別々のものを作る。
数回ではなく、現在ターミナルで動作しているEAの数で。
そのため、各EAが独自に注文を処理する必要がある