OnTradeTransaction関数について質問です。 - ページ 4 1234567 新しいコメント Sergey Chalyshev 2015.02.05 22:38 #31 Mikalas:それは、取引所に厨房がいない（手数料のみ）ことと、FOREXに数百万人のMMM信者がいるためです。100円でも、EVERYONEは持っています。巨額の資金、数えるほどしかない!:)MetaQuotesがよくわからない )FX厨には、素晴らしいMT4ターミナルがある。 多くのFX厨はMT5経由のアクセスを提供しない、必要ないんだよ。取引所に近いターミナルを作るのは、これだけの年月があっても無理なのでしょうか？良いターミナルを持っていれば、MT5サービスを提供したい顧客がたくさんいるはずです。 Mikhail Filimonov 2015.02.05 22:46 #32 Serj_Che:MetaQuotesがよくわからない )FX厨には、素晴らしいMT4ターミナルがある。 多くのFX厨はMT5経由のアクセスを提供しない、必要ないんだよ。取引所に近いターミナルを作るのは、これだけの年月があっても無理なのでしょうか？良い端末があれば、MT5のサービスを提供したいクライアントがたくさんいるはずです。MQではなく、ブローカーの話です。ブローカーは、顧客が取引をすることで、より多くの取引、より多くの手数料を得ることができます。ロボットは「正しい取引」しかしませんし、「手で」注文を出すことで、人はとてもロボットは「正しい」取引しかしませんし、ハンドオーダーでは人はよくミスをします（私も何度もミスをしました）。トラブルに巻き込まれる、悪態をつく、損失で注文を閉じる、取り戻したい、また設定を間違えた、などなど。そして、ブローカーと取引所は手数料を得た :) ですから、取引所にとって、特にブローカーにとってQUIKは母国なのです。 Vasiliy Sokolov 2015.02.06 06:01 #33 Mikalas:ワシリー、答えはあるのか？そんなことはないだろう。私は勝ったのか？ 今夜、答えを出します。今は無理です。 Alexey Viktorov 2015.02.06 09:20 #34 C-4:物事を複雑にしないでください。FORTSで取引するために非同期を使用する必要はありません。まずは、こちらの記事、第3章「非同期操作の基本」をご覧ください。大したことはなく、ごく基本的なことですが、勉強を始めるには十分です。そこで説明されているコードは100％非同期ですが、しかし、同期モードでもあらゆる種類のOnTradeTransactionや他のイベントを取得することなく動作することを妨げるものではありません。課題に基づいて解決する必要があります。MetaTrader5では、アクティブなポジションは常に1つだけなので、気をつけましょう。注文履歴を調べる必要はありません。それでも注文履歴が必要な場合は、目的を明確にする必要があります。いや、ヴァシリー、あなたは私の目的をよく理解していない。私は、FORTSで何かを書いたり、トレードしたりするつもりはなく、mql5を勉強し始めたばかりです。先ほどからこの記事を読んでいます。でも、2ページも読めずに諦めています。自分もNTだから必要ないと思う。しかし、OrderSendとOrderSendAsyncの違いを明確に説明することは有用である。ほぼ予想通りですね。非同期注文送信をスキップして、OnTradeTransaction を使用して口座で何が起こっているかを追跡すれば、EA のパフォーマンスが向上するのではないでしょうか？刻み目ごとにチェックを行うことと、アカウントに何らかの変化があった場合のみチェックを行うことは全く別物である。私が間違っているのでしょうか？保留中の注文が有効になった、それに関する情報を持っている。ポジションがクローズされた場合、その結果を分析することができます。ポジションのオープンからクローズまでの間、数回のチェックが行われるだけです。そして、それとは対照的に、すべてのティックにチェックが入っている...。もう一つの質問ですが、ポジションの利益を決定するために、PositionGetDouble(POSITION_PROFIT) 関数がありますが、クローズしたポジションの利益を決定するために、 OrderCalcProfit()のみ 、この取引から最初に取得しなければならないパラメータが山ほど あります。それとも、私がmql5を使い始めたばかりで、適切な解決策が見つからないのでしょうか？もしよろしければ... Mikhail Filimonov 2015.02.07 00:25 #35 AlexeyVik:いいえ、ヴァシリー、あなたは私の目的を誤解しています。まだmql5を勉強し始めたばかりで、FORTSで何かを書いたり、トレードしたりするつもりはないです。さっきからこの記事を読んでいます。でも、2ページも読めずに諦めています。自分もNTだから必要ないと思う。しかし、OrderSendとOrderSendAsyncの違いを明確に説明することは有用である。ほぼ予想通りですね。非同期注文送信を破棄しても、OnTradeTransaction を使用して口座で何が起こっているかを追跡すれば、EA のパフォーマンスが向上するのではないでしょうか？毎回のクリックでチェックを行うことと、アカウントに何らかの変化があった場合のみチェックを行うことは、全く別のことです。私が間違っているのでしょうか？保留中の注文が有効になった、それに関する情報を持っている。ポジションがクローズされた場合、その結果を分析することができます。ポジションのオープンからクローズまでの間、数回のチェックが行われるだけです。そして、それとは対照的に、すべてのティックにチェックが入っている...。もう一つの質問ですが、ポジションの利益を決定するために、PositionGetDouble(POSITION_PROFIT) 関数がありますが、クローズしたポジションの利益を決定するために、 OrderCalcProfit()のみ 、このトレードから最初に取得しなければならないパラメータが山ほど あります。それとも、私がmql5を使い始めたばかりで、適切な解決策が見つからないのでしょうか？ご面倒でなければ...。OrderCalcProfitは役に立ちません。全注文の平均価格（in）と全注文の平均価格（out）を計算する必要があります。であれば、クローズドポジションの 利益を計算することができます。歴史に目を通す必要がありそうです。 Alexey Viktorov 2015.02.07 07:01 #36 Mikalas:OrderCalcProfitは役に立ちません。全注文の平均価格（in）と全注文の平均価格（out）を計算する必要があります。そして、クローズしたポジションの 利益を計算することができます。歴史を調べる必要がありそうだ。原理的には理解できるのですが（やり方はまだ理解していませんが）、この場合、私にとって重要なのは最後のクローズポジションだけなのです。どうやらこれは、ポジションが埋まった時の方が向いているようだ。でも、私の仕事は違います。mql5のフクロウをmartinで書き直すことにしました。継続的に市場に存在し、最後のポジションに向かって次のトレードを開始する...おっと...というのは、それだけ掲示板でのコミュニケーションが有効だということです。結局、保留注文が発動した時にポジションが反転するか、テイクで閉じるしかないのであれば、損益の大きさは気にならないのです。まあ、最後の膝でマイナスが出るなら、何もいらないか...。クローズしたポジションの種類を知るだけで十分です。そして、これはOnTradeTransactionハンドラでTRADE_TRANSACTION_DEAL_ADDと TRADE_TRANSACTION_HISTORY_ADDの トランザクションタイプでグローバルレベルの変数に書き込むことができますし、 PositionsTotalが0 であれば 次のシリーズの最初の注文を入れても 良いでしょう...。 忘れないように、自分のために書いておきました :))) Denis Kirichenko 2015.02.07 10:11 #37 papaklass:...つまり、アルゴリズムのロジックは、関数やイベントの処理ではなく、TRADING ENVIRONMENT CHANGEに基づくものであるべきです。3 取引環境を確認する頻度（ティック上、バー上、タイマー上など）は、お客様のTSのロジックに対応する必要があります。つまり、取引環境の変化をどれくらいのスピードで処理すべきなのか？TSのロジックで、できるだけ早く変更を処理する必要がある場合、毎回のティックでチェックすることから逃れることはできませんが...。 EAがマルチカレンシーである場合は ？ Alexey Viktorov 2015.02.07 10:12 #38 papaklass:1.OrderSendAsync()関数は、複数の注文を一度に送信する必要がある場合、つまり一種のバッチ送信に使用されます。一括送信の場合、各注文に対してサーバーが応答するのを待つと（OrderSend()関数を使用）、全体の一括送信にかなりのトータルタイムラグが生じます。このタイムラグの間に、市場は大きく変化する可能性がありますこのタイムラグを回避するために、OrderSendAsync()関数を導入しています。これを明確に理解する必要があります。 注文を一括して送信する必要がない場合は、OrderSendAsync()関数を使用する意味がありません。注文、オーダーなどがトリガーされたかどうかを判断する最も確実な方法は、取引環境をモニターすることです。- は、取引環境を追跡するものであり、機能やイベントをトリガーするものではありません。機能やイベントが機能しても、それが取引環境を変えるとは限りません。 なぜ？なぜなら、関数の実行中に単純にエラーが発生することがあるからです。 したがって、アルゴリズムのロジックは、VARIABLE CHANGEに基づくものでなければならず、関数やイベントの処理に基づくものであってはならない。3. 取引環境をチェックする頻度（ティック上、バー上、タイマーによる、など）が、お客様のTSのロジックに合っている必要があります。つまり、取引環境の変化をどれだけ早く処理する必要があるかということです。 TSのロジックで、できるだけ早く変更を処理する必要がある場合、すべてのティックでチェックしないわけにはいきません。 アレクサンダーさん、ご感想ありがとうございます。今のところ必要ないことだけは理解しています。今のところOrderSendの機能で十分です。2.そうですね、環境全体を刻々と監視することでしか、最も正確な状態を判断することができないのは同意します。しかし、そのようなイベントハンドラを持っていても、それを無視するのは......。まあ、実験的なものですが。何とかして信頼性を高めたいという気持ちはよくわかるのですが、私の目的は違います。このExpert Advisorは緊急に必要なものではないし、注文して書いているわけでもない。3.おそらくEAの最終バージョンでは、すべてのティックでテストすることに戻ると思いますが、今のところは...。問題は、OnTradeTransaction イベントハンドラについて、文書で警告されている場合、それを信頼できるかどうかでした。 また、サーバーから端末への配信でトランザクションが失われる可能性もある。そして、どのような場合は信用しないほうがいいのか、どのような場合は何かで裏付けをとる必要があるのか、です。Vasiliy、Michael、そしてあなた方Alexander、みんなにとても感謝しています。また何か感想を聞かせていただければ、とても嬉しく、また感謝いたします。 Alexey Viktorov 2015.02.07 11:50 #39 papaklass:これこそ、ヴァシリーも私も答えた疑問である。考えてみれば、OnTradeTransaction()関数の 動作を一通り確認しなければならないのであれば、OnTradeTransaction()が処理された後ではなく、すぐに取引環境を確認した方がよいかもしれません。しかし、それは好みの問題です。そして、次のスレッドでRenatはこの機能で作業することを約束し、おそらく次のビルドでこの機能の改善がなされるでしょう。しかし、それでも私たちは、非同期で注文を出すことにこだわっています。この場合、何百もの注文の中から1つでも失う理由はないのです。しかし、マイケル氏は、6ヶ月間、非常に多くの注文がある中で、一度も取引を失ったことがないと言う。また、OrderSend()関数を使って注文した場合、取引に失敗する確率はどのくらいでしょうか。また、改善が進むとすれば、それはもう一つの懸念材料です。それとも、私がまた間違っているのでしょうか？ Denis Kirichenko 2015.02.07 12:32 #40 denkir: А если советник мультивалютный?papaklass何を言ってほしいのか、はっきりしない。イベントモデルへの 反論... 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
それは、取引所に厨房がいない（手数料のみ）ことと、FOREXに数百万人のMMM信者がいるためです。
100円でも、EVERYONEは持っています。巨額の資金、数えるほどしかない!:)
MetaQuotesがよくわからない )
FX厨には、素晴らしいMT4ターミナルがある。
多くのFX厨はMT5経由のアクセスを提供しない、必要ないんだよ。
取引所に近いターミナルを作るのは、これだけの年月があっても無理なのでしょうか？
良いターミナルを持っていれば、MT5サービスを提供したい顧客がたくさんいるはずです。
MetaQuotesがよくわからない )
FX厨には、素晴らしいMT4ターミナルがある。
多くのFX厨はMT5経由のアクセスを提供しない、必要ないんだよ。
取引所に近いターミナルを作るのは、これだけの年月があっても無理なのでしょうか？
良い端末があれば、MT5のサービスを提供したいクライアントがたくさんいるはずです。
MQではなく、ブローカーの話です。
ブローカーは、顧客が取引をすることで、より多くの取引、より多くの手数料を得ることができます。
ロボットは「正しい取引」しかしませんし、「手で」注文を出すことで、人はとても
ロボットは「正しい」取引しかしませんし、ハンドオーダーでは人はよくミスをします（私も何度もミスをしました）。
トラブルに巻き込まれる、悪態をつく、損失で注文を閉じる、取り戻したい、また設定を間違えた、などなど。
そして、ブローカーと取引所は手数料を得た :)
ですから、取引所にとって、特にブローカーにとってQUIKは母国なのです。
ワシリー、答えはあるのか？
そんなことはないだろう。
私は勝ったのか？
物事を複雑にしないでください。FORTSで取引するために非同期を使用する必要はありません。まずは、こちらの記事、第3章「非同期操作の基本」をご覧ください。大したことはなく、ごく基本的なことですが、勉強を始めるには十分です。そこで説明されているコードは100％非同期ですが、しかし、同期モードでもあらゆる種類のOnTradeTransactionや他のイベントを取得することなく動作することを妨げるものではありません。
課題に基づいて解決する必要があります。MetaTrader5では、アクティブなポジションは常に1つだけなので、気をつけましょう。注文履歴を調べる必要はありません。それでも注文履歴が必要な場合は、目的を明確にする必要があります。
いや、ヴァシリー、あなたは私の目的をよく理解していない。私は、FORTSで何かを書いたり、トレードしたりするつもりはなく、mql5を勉強し始めたばかりです。先ほどからこの記事を読んでいます。でも、2ページも読めずに諦めています。自分もNTだから必要ないと思う。しかし、OrderSendとOrderSendAsyncの違いを明確に説明することは有用である。ほぼ予想通りですね。
非同期注文送信をスキップして、OnTradeTransaction を使用して口座で何が起こっているかを追跡すれば、EA のパフォーマンスが向上するのではないでしょうか？
刻み目ごとにチェックを行うことと、アカウントに何らかの変化があった場合のみチェックを行うことは全く別物である。私が間違っているのでしょうか？保留中の注文が有効になった、それに関する情報を持っている。ポジションがクローズされた場合、その結果を分析することができます。ポジションのオープンからクローズまでの間、数回のチェックが行われるだけです。そして、それとは対照的に、すべてのティックにチェックが入っている...。
もう一つの質問ですが、ポジションの利益を決定するために、PositionGetDouble(POSITION_PROFIT) 関数がありますが、クローズしたポジションの利益を決定するために、 OrderCalcProfit()のみ 、この取引から最初に取得しなければならないパラメータが山ほど あります。それとも、私がmql5を使い始めたばかりで、適切な解決策が見つからないのでしょうか？
もしよろしければ...
いいえ、ヴァシリー、あなたは私の目的を誤解しています。まだmql5を勉強し始めたばかりで、FORTSで何かを書いたり、トレードしたりするつもりはないです。さっきからこの記事を読んでいます。でも、2ページも読めずに諦めています。自分もNTだから必要ないと思う。しかし、OrderSendとOrderSendAsyncの違いを明確に説明することは有用である。ほぼ予想通りですね。
非同期注文送信を破棄しても、OnTradeTransaction を使用して口座で何が起こっているかを追跡すれば、EA のパフォーマンスが向上するのではないでしょうか？
毎回のクリックでチェックを行うことと、アカウントに何らかの変化があった場合のみチェックを行うことは、全く別のことです。私が間違っているのでしょうか？保留中の注文が有効になった、それに関する情報を持っている。ポジションがクローズされた場合、その結果を分析することができます。ポジションのオープンからクローズまでの間、数回のチェックが行われるだけです。そして、それとは対照的に、すべてのティックにチェックが入っている...。
もう一つの質問ですが、ポジションの利益を決定するために、PositionGetDouble(POSITION_PROFIT) 関数がありますが、クローズしたポジションの利益を決定するために、 OrderCalcProfit()のみ 、このトレードから最初に取得しなければならないパラメータが山ほど あります。それとも、私がmql5を使い始めたばかりで、適切な解決策が見つからないのでしょうか？
ご面倒でなければ...。
OrderCalcProfitは役に立ちません。
全注文の平均価格（in）と全注文の平均価格（out）を計算する必要があります。
であれば、クローズドポジションの 利益を計算することができます。
歴史に目を通す必要がありそうです。
OrderCalcProfitは役に立ちません。
全注文の平均価格（in）と全注文の平均価格（out）を計算する必要があります。
そして、クローズしたポジションの 利益を計算することができます。
歴史を調べる必要がありそうだ。
原理的には理解できるのですが（やり方はまだ理解していませんが）、この場合、私にとって重要なのは最後のクローズポジションだけなのです。どうやらこれは、ポジションが埋まった時の方が向いているようだ。でも、私の仕事は違います。
mql5のフクロウをmartinで書き直すことにしました。継続的に市場に存在し、最後のポジションに向かって次のトレードを開始する...
おっと...というのは、それだけ掲示板でのコミュニケーションが有効だということです。結局、保留注文が発動した時にポジションが反転するか、テイクで閉じるしかないのであれば、損益の大きさは気にならないのです。まあ、最後の膝でマイナスが出るなら、何もいらないか...。クローズしたポジションの種類を知るだけで十分です。そして、これはOnTradeTransactionハンドラでTRADE_TRANSACTION_DEAL_ADDと TRADE_TRANSACTION_HISTORY_ADDの トランザクションタイプでグローバルレベルの変数に書き込むことができますし、 PositionsTotalが0 であれば 次のシリーズの最初の注文を入れても 良いでしょう...。 忘れないように、自分のために書いておきました :)))
...つまり、アルゴリズムのロジックは、関数やイベントの処理ではなく、TRADING ENVIRONMENT CHANGEに基づくものであるべきです。
3 取引環境を確認する頻度（ティック上、バー上、タイマー上など）は、お客様のTSのロジックに対応する必要があります。つまり、取引環境の変化をどれくらいのスピードで処理すべきなのか？TSのロジックで、できるだけ早く変更を処理する必要がある場合、毎回のティックでチェックすることから逃れることはできませんが...。
1.OrderSendAsync()関数は、複数の注文を一度に送信する必要がある場合、つまり一種のバッチ送信に使用されます。一括送信の場合、各注文に対してサーバーが応答するのを待つと（OrderSend()関数を使用）、全体の一括送信にかなりのトータルタイムラグが生じます。このタイムラグの間に、市場は大きく変化する可能性がありますこのタイムラグを回避するために、OrderSendAsync()関数を導入しています。これを明確に理解する必要があります。
注文を一括して送信する必要がない場合は、OrderSendAsync()関数を使用する意味がありません。
注文、オーダーなどがトリガーされたかどうかを判断する最も確実な方法は、取引環境をモニターすることです。- は、取引環境を追跡するものであり、機能やイベントをトリガーするものではありません。機能やイベントが機能しても、それが取引環境を変えるとは限りません。 なぜ？なぜなら、関数の実行中に単純にエラーが発生することがあるからです。
したがって、アルゴリズムのロジックは、VARIABLE CHANGEに基づくものでなければならず、関数やイベントの処理に基づくものであってはならない。
3. 取引環境をチェックする頻度（ティック上、バー上、タイマーによる、など）が、お客様のTSのロジックに合っている必要があります。つまり、取引環境の変化をどれだけ早く処理する必要があるかということです。 TSのロジックで、できるだけ早く変更を処理する必要がある場合、すべてのティックでチェックしないわけにはいきません。
アレクサンダーさん、ご感想ありがとうございます。
今のところ必要ないことだけは理解しています。今のところOrderSendの機能で十分です。
2.そうですね、環境全体を刻々と監視することでしか、最も正確な状態を判断することができないのは同意します。しかし、そのようなイベントハンドラを持っていても、それを無視するのは......。まあ、実験的なものですが。何とかして信頼性を高めたいという気持ちはよくわかるのですが、私の目的は違います。このExpert Advisorは緊急に必要なものではないし、注文して書いているわけでもない。
3.おそらくEAの最終バージョンでは、すべてのティックでテストすることに戻ると思いますが、今のところは...。
問題は、OnTradeTransaction イベントハンドラについて、文書で警告されている場合、それを信頼できるかどうかでした。
また、サーバーから端末への配信でトランザクションが失われる可能性もある。
そして、どのような場合は信用しないほうがいいのか、どのような場合は何かで裏付けをとる必要があるのか、です。
Vasiliy、Michael、そしてあなた方Alexander、みんなにとても感謝しています。また何か感想を聞かせていただければ、とても嬉しく、また感謝いたします。
これこそ、ヴァシリーも私も答えた疑問である。
考えてみれば、OnTradeTransaction()関数の 動作を一通り確認しなければならないのであれば、OnTradeTransaction()が処理された後ではなく、すぐに取引環境を確認した方がよいかもしれません。しかし、それは好みの問題です。
そして、次のスレッドでRenatはこの機能で作業することを約束し、おそらく次のビルドでこの機能の改善がなされるでしょう。
しかし、それでも私たちは、非同期で注文を出すことにこだわっています。この場合、何百もの注文の中から1つでも失う理由はないのです。しかし、マイケル氏は、6ヶ月間、非常に多くの注文がある中で、一度も取引を失ったことがないと言う。また、OrderSend()関数を使って注文した場合、取引に失敗する確率はどのくらいでしょうか。
また、改善が進むとすれば、それはもう一つの懸念材料です。それとも、私がまた間違っているのでしょうか？
А если советник мультивалютный?
papaklass
何を言ってほしいのか、はっきりしない。