初心者の方からの質問 MQL5 MT5 MetaTrader 5 - ページ 1099 1...109210931094109510961097109810991100110111021103110411051106...1503 新しいコメント Artyom Trishkin 2019.07.21 16:18 #10981 Igor Makanu: ありがとうございました。 そう、それがSBで「5行」で書けないか、ということです。 しかし、1つのSB CTradeが 私の問題を解決することができないことをどれだけ理解しましたか？ そして、私はCPositionInfoも使用しなければならなかったのですか？- 複数のTFによる9つのポジションを同時に同行させたい場合？ ZS：私はスマートテレビでMQL5ヘルプに座っている - かなりよく貿易関数を 説明し、SatBの使用は、質問の下にある....私はプリミティブ戦略、少し複雑なためにSBを使用することは理にかなっていると思う - 機能が不十分であるか、または明白ではない使用、多分私はより多くの練習が必要 - 私はSBを "ひねり "に挑戦します。 いつもありがとうございます。 テスターでの「ポジションの開閉」、トレーニングコードの代用としてOKです。そうでない場合は、自分でコードを作成するか、CTradeから継承して、様々なニュアンスを考慮した独自の本格的な取引操作用クラスを作成する必要があります。 SBにはもっと素敵なものがある。それを知っていて使う。 Artyom Trishkin 2019.07.21 16:18 #10982 fxsaber: リストはHistorySelectByPositionによって生成されるため、そこにエラーはありません。 そうですね、完全なリストでないことは見落としていました。 Igor Makanu 2019.07.21 16:33 #10983 Artyom Trishkin: SBにはもっと素敵なものがある。それを知っていて使っているのだから。 ということで、これらは誤解を恐れずに言えば、いいことづくめです- 長い年月を経て、開発者がきれいになって期待通りの機能を作ってくれて、私はSBの2クリックが使えなかっただけのユーザーだと期待していたのですが、私がユーザーではないことが判明しました～悲しい、悲しいの一点張りです SZY: MQL5のヘルプは非常に巧みに書かれていて、注文がいっぱいです。でも、語順を忘れるまでは、絶望的だそうです。 Artyom Trishkin 2019.07.21 16:56 #10984 Igor Makanu: ということで、これらは誤解を恐れずに言えば、いいことづくめです- 長い年月の間にSBの開発者が期待通りの機能を磨き上げて作ってくれていて、私は2クリックでSBを使いこなせないただのユーザーだと期待していたのですが、私がユーザーではないことが判明し、一般的に悲しいことに......です。 SZY: MQL5のヘルプは非常に巧みに書かれていて、注文がいっぱいです。でも、語順を忘れるまでは、絶望的だそうです。 ここは極めてシンプルです。注文→取引→ポジションMQL5では、オーダーを避けることはできません。オーダーはそこにあり、すべての始まりなのです。私たちはサーバーに取引要求を送り（それは注文です）、サーバーはそれを受け入れ/受信し、コードを返します。リクエストが正しくない場合、注文はサーバーに送信されず、端末レベルで送信がブロックされることがあります。注文がサーバーに正常に送信され、実行のためにキューに入れられると、この注文がトリガー（その実行、言い換えれば取引）されるのを待ち、この取引の結果として（それが成行注文であれ、保留注文であれ）、ポジションが形成されます（常にではありません - ネッティングで、同じ方向にポジションがある場合、それは単に既存のポジションにボリュームを追加し、反対方向なら、次に、コミットした取引のボリュームに応じて、現在のポジションは、一部閉鎖または逆行します）。 オーダーも専用のチケットを持っています。トレードやポジションもそうです。しかし、ポジションには識別子もあります。ポジションの識別子は、常にその最初の注文（このポジションを開くための注文）のチケットと同じになります。 成行注文は、チケットのみを持つ。また、そのポジション識別子のプロパティは、注文がトリガーされるまで満たされません。つまり、履歴のある注文だけがポジション識別子を持ち、それは取引の瞬間、つまりその注文がトリガーされた瞬間に記入されるのです。削除された保留中の注文の 場合、そのポジションの識別子も埋められません - 取引もポジションもそれぞれありませんでした。 取引にはチケット（そのチケット）があり、注文の識別子（この取引が執行された結果）があり、ポジションの識別子（この取引が執行された結果現れたポジション、この取引が執行された結果変更されたポジション）があります。 ポジションにはチケットがあり、オープン時や変更時に割り当てられます。ポジションがオープンされただけなら、そのチケットは識別子と同じになります。これはユニークなポジション番号で、ポジションの存続期間を通じて変わることはありません。ポジションのチケットは繰り返し変更され、ある注文のチケットと対応することがありますが、その注文のトリガーの結果、そのポジションを変更する新しいトレードが現れ、その注文のチケットがポジションのチケットに割り振られます。 このようなポジションの変容を注意深く観察すると、mql4の部分終値のポジションの挙動を簡単に見ることができます - そのチケットもそこで変化します。 Igor Makanu 2019.07.21 17:15 #10985 Artyom Trishkin: このような位置の変容をよく見てみると ありがとうございます。2日目も見ていますが、必要なのは練習です、今日はSBがわかりました...いや、わかりましたよ;) PS：説明が上手ですね、才能があるのは確かです。 Artyom Trishkin 2019.07.21 17:15 #10986 Igor Makanu: ありがとうございました。日目も見ていますが、練習あるのみなので、今日はSBの整理を...いや、整理しました(^^) PS:よく説明してくれた、間違いなく才能だ! 喜んでお手伝いします ;) 削除済み 2019.07.21 18:41 #10987 Artyom Trishkin: また、注文にはチケットが必要です。トレードやポジションもそうです。しかし、ポジションには識別子もあります。ポジションの識別子は、常にその最初の注文（このポジションを開くための注文）のチケットと同じになります。 成行注文は、チケットのみを持つ。また、そのポジション識別子のプロパティは、注文がトリガーされるまで満たされません。つまり、履歴のある注文だけがポジション識別子を持ち、それは取引を実行する瞬間、つまりその注文がトリガーされた瞬間に記入されるのです。 削除された保留中の注文の 場合、そのポジションの識別子も埋められません - 取引もポジションもそれぞれありませんでした。 取引にはチケット（そのチケット）があり、注文の識別子（この取引が執行された結果）があり、ポジションの識別子（この取引が執行された結果現れたポジションまたはこの取引が執行された結果変更されたポジション）があります。 ポジションにはチケットがあり、オープン時や変更時に割り当てられます。ポジションがオープンされただけであれば、チケットはその識別子（ユニークなポジション番号）と同じになります。ポジションのチケットは繰り返し変更可能で、注文チケットと対応していますが、その注文がトリガーされた結果、そのポジションを変更する新しいトレードが出現すると、その注文のチケットはポジションチケットに割り振られます。 このようなポジションの変容を注意深く観察すると、mql4の部分終値のポジションの挙動を簡単に見ることができます - そのチケットもそこで変化します。 つまり、注文を取引にするのが遅れたためにミスマッチが 生じたことが判明したわけですが、ポジション？テスターでも...？すごいですね。 だから、注文が入った後も、ポジションが開くようにしなければならないのですが...。どのくらい待たされるのですか？すべての変換が確定するまで、フクロウを吊るすことでしょうか。あるいは、一般的にはどのようなものなのでしょうか？ Vladimir Karputov 2019.07.21 18:47 #10988 Сергей Таболин: ミスマッチは、注文を取引にするのが遅れたことが原因だと判明した - ポジション？テスターでも...？なんということでしょう。 だから、注文を出した後も、ポジションがオープンされたことを確認しなければならない...。どのくらい待たされるのですか？すべての変換が確定するまで、フクロウを吊るすことでしょうか。あるいは、一般的にはどのようなものなのでしょうか？ 取引注文を出し（取引チケットを記憶している）、待機フラグを立てた - OnTradeTransaction で保証されたトリガー（取引タイプ TRADE_TRANSACTION_DEAL_ADD）を得るとすぐに、取引チケットをチェックする - 取引チケットをチェックすると、取引チケットがある。すべてがうまくいくのであれば、いいのですが......。 これは実生活です。イベントは異なる間隔、接続の故障で来るかもしれません...。いろいろなことが起こりうる。これが現実で、リジッドチェーンは存在しない。 削除済み 2019.07.21 19:10 #10989 Vladimir Karputov: 取引注文を出し（取引チケットを記憶）、保留フラグを設定した - OnTradeTransaction が保証されたトリガー（取引タイプ TRADE_TRANSACTION_DEAL_ADD）を受け取るとすぐに、取引チケットをチェックします。すべてがうまくいくのであれば、いいのですが......。 これは実生活です。イベントは異なる間隔、接続の故障で来るかもしれません...。いろいろなことが起こりうる。これが現実で、リジッドチェーンは存在しない。 まあそれは本質的に参議院議員を吊るし上げることになるのだが......。確認が来るか来ないか待っているところ...。ここで途方に暮れてしまう...。この待ち時間はどうすればいいのでしょうか？while()の使用 ? Vladimir Karputov 2019.07.21 19:11 #10990 Сергей Таболин:これでは本来、参議院議員を吊るし上げることになる...。確認が来るか来ないか待っているところ...。私はここで途方に暮れています。この待ち時間はどうすればいいのでしょうか？while()の使用 ? いいえ、寝ながらは 禁止されています。 1...109210931094109510961097109810991100110111021103110411051106...1503 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ありがとうございました。
そう、それがSBで「5行」で書けないか、ということです。
しかし、1つのSB CTradeが 私の問題を解決することができないことをどれだけ理解しましたか？ そして、私はCPositionInfoも使用しなければならなかったのですか？- 複数のTFによる9つのポジションを同時に同行させたい場合？
ZS：私はスマートテレビでMQL5ヘルプに座っている - かなりよく貿易関数を 説明し、SatBの使用は、質問の下にある....私はプリミティブ戦略、少し複雑なためにSBを使用することは理にかなっていると思う - 機能が不十分であるか、または明白ではない使用、多分私はより多くの練習が必要 - 私はSBを "ひねり "に挑戦します。
いつもありがとうございます。
テスターでの「ポジションの開閉」、トレーニングコードの代用としてOKです。そうでない場合は、自分でコードを作成するか、CTradeから継承して、様々なニュアンスを考慮した独自の本格的な取引操作用クラスを作成する必要があります。
SBにはもっと素敵なものがある。それを知っていて使う。
リストはHistorySelectByPositionによって生成されるため、そこにエラーはありません。
そうですね、完全なリストでないことは見落としていました。
SBにはもっと素敵なものがある。それを知っていて使っているのだから。
ということで、これらは誤解を恐れずに言えば、いいことづくめです- 長い年月を経て、開発者がきれいになって期待通りの機能を作ってくれて、私はSBの2クリックが使えなかっただけのユーザーだと期待していたのですが、私がユーザーではないことが判明しました～悲しい、悲しいの一点張りです
SZY: MQL5のヘルプは非常に巧みに書かれていて、注文がいっぱいです。でも、語順を忘れるまでは、絶望的だそうです。
ということで、これらは誤解を恐れずに言えば、いいことづくめです- 長い年月の間にSBの開発者が期待通りの機能を磨き上げて作ってくれていて、私は2クリックでSBを使いこなせないただのユーザーだと期待していたのですが、私がユーザーではないことが判明し、一般的に悲しいことに......です。
SZY: MQL5のヘルプは非常に巧みに書かれていて、注文がいっぱいです。でも、語順を忘れるまでは、絶望的だそうです。
ここは極めてシンプルです。注文→取引→ポジションMQL5では、オーダーを避けることはできません。オーダーはそこにあり、すべての始まりなのです。私たちはサーバーに取引要求を送り（それは注文です）、サーバーはそれを受け入れ/受信し、コードを返します。リクエストが正しくない場合、注文はサーバーに送信されず、端末レベルで送信がブロックされることがあります。注文がサーバーに正常に送信され、実行のためにキューに入れられると、この注文がトリガー（その実行、言い換えれば取引）されるのを待ち、この取引の結果として（それが成行注文であれ、保留注文であれ）、ポジションが形成されます（常にではありません - ネッティングで、同じ方向にポジションがある場合、それは単に既存のポジションにボリュームを追加し、反対方向なら、次に、コミットした取引のボリュームに応じて、現在のポジションは、一部閉鎖または逆行します）。
オーダーも専用のチケットを持っています。トレードやポジションもそうです。しかし、ポジションには識別子もあります。ポジションの識別子は、常にその最初の注文（このポジションを開くための注文）のチケットと同じになります。
成行注文は、チケットのみを持つ。また、そのポジション識別子のプロパティは、注文がトリガーされるまで満たされません。つまり、履歴のある注文だけがポジション識別子を持ち、それは取引の瞬間、つまりその注文がトリガーされた瞬間に記入されるのです。削除された保留中の注文の 場合、そのポジションの識別子も埋められません - 取引もポジションもそれぞれありませんでした。
取引にはチケット（そのチケット）があり、注文の識別子（この取引が執行された結果）があり、ポジションの識別子（この取引が執行された結果現れたポジション、この取引が執行された結果変更されたポジション）があります。
ポジションにはチケットがあり、オープン時や変更時に割り当てられます。ポジションがオープンされただけなら、そのチケットは識別子と同じになります。これはユニークなポジション番号で、ポジションの存続期間を通じて変わることはありません。ポジションのチケットは繰り返し変更され、ある注文のチケットと対応することがありますが、その注文のトリガーの結果、そのポジションを変更する新しいトレードが現れ、その注文のチケットがポジションのチケットに割り振られます。
このようなポジションの変容を注意深く観察すると、mql4の部分終値のポジションの挙動を簡単に見ることができます - そのチケットもそこで変化します。
このような位置の変容をよく見てみると
ありがとうございます。2日目も見ていますが、必要なのは練習です、今日はSBがわかりました...いや、わかりましたよ;)
PS：説明が上手ですね、才能があるのは確かです。
ありがとうございました。日目も見ていますが、練習あるのみなので、今日はSBの整理を...いや、整理しました(^^)
PS:よく説明してくれた、間違いなく才能だ!
喜んでお手伝いします ;)
また、注文にはチケットが必要です。トレードやポジションもそうです。しかし、ポジションには識別子もあります。ポジションの識別子は、常にその最初の注文（このポジションを開くための注文）のチケットと同じになります。
成行注文は、チケットのみを持つ。また、そのポジション識別子のプロパティは、注文がトリガーされるまで満たされません。つまり、履歴のある注文だけがポジション識別子を持ち、それは取引を実行する瞬間、つまりその注文がトリガーされた瞬間に記入されるのです。 削除された保留中の注文の 場合、そのポジションの識別子も埋められません - 取引もポジションもそれぞれありませんでした。
取引にはチケット（そのチケット）があり、注文の識別子（この取引が執行された結果）があり、ポジションの識別子（この取引が執行された結果現れたポジションまたはこの取引が執行された結果変更されたポジション）があります。
ポジションにはチケットがあり、オープン時や変更時に割り当てられます。ポジションがオープンされただけであれば、チケットはその識別子（ユニークなポジション番号）と同じになります。ポジションのチケットは繰り返し変更可能で、注文チケットと対応していますが、その注文がトリガーされた結果、そのポジションを変更する新しいトレードが出現すると、その注文のチケットはポジションチケットに割り振られます。
このようなポジションの変容を注意深く観察すると、mql4の部分終値のポジションの挙動を簡単に見ることができます - そのチケットもそこで変化します。
つまり、注文を取引にするのが遅れたためにミスマッチが 生じたことが判明したわけですが、ポジション？テスターでも...？すごいですね。
だから、注文が入った後も、ポジションが開くようにしなければならないのですが...。どのくらい待たされるのですか？すべての変換が確定するまで、フクロウを吊るすことでしょうか。あるいは、一般的にはどのようなものなのでしょうか？
ミスマッチは、注文を取引にするのが遅れたことが原因だと判明した - ポジション？テスターでも...？なんということでしょう。
だから、注文を出した後も、ポジションがオープンされたことを確認しなければならない...。どのくらい待たされるのですか？すべての変換が確定するまで、フクロウを吊るすことでしょうか。あるいは、一般的にはどのようなものなのでしょうか？
取引注文を出し（取引チケットを記憶している）、待機フラグを立てた - OnTradeTransaction で保証されたトリガー（取引タイプ TRADE_TRANSACTION_DEAL_ADD）を得るとすぐに、取引チケットをチェックする - 取引チケットをチェックすると、取引チケットがある。すべてがうまくいくのであれば、いいのですが......。
これは実生活です。イベントは異なる間隔、接続の故障で来るかもしれません...。いろいろなことが起こりうる。これが現実で、リジッドチェーンは存在しない。
取引注文を出し（取引チケットを記憶）、保留フラグを設定した - OnTradeTransaction が保証されたトリガー（取引タイプ TRADE_TRANSACTION_DEAL_ADD）を受け取るとすぐに、取引チケットをチェックします。すべてがうまくいくのであれば、いいのですが......。
これは実生活です。イベントは異なる間隔、接続の故障で来るかもしれません...。いろいろなことが起こりうる。これが現実で、リジッドチェーンは存在しない。
まあそれは本質的に参議院議員を吊るし上げることになるのだが......。確認が来るか来ないか待っているところ...。ここで途方に暮れてしまう...。この待ち時間はどうすればいいのでしょうか？while()の使用 ?
これでは本来、参議院議員を吊るし上げることになる...。確認が来るか来ないか待っているところ...。私はここで途方に暮れています。この待ち時間はどうすればいいのでしょうか？while()の使用 ?
いいえ、寝ながらは 禁止されています。