レプリカです。何百万人が訪れ、何百万人が去っていく。長い間、慣習的に言えば、ごく1％の人たちが残っている。つまり、CCAやIf-Doneを、特別な精神的成長を必要とする不思議な道具だと考えていない人たちです。この1％は数万人の「上級者」で構成されるでしょうから、「OCO-order only forcurrent positions (SL-TP)」で済むのか、それとも数百の質問が出るのか、見てみましょう。すでに今、MT5が大量に使われていないにもかかわらず、今のところ少数ではあるが、このトピックに関心が持たれている。
携帯電話端末について教えてください。
ユーザー指標（非標準）のサポートや、mql4やmql5に関するコンサルティングはいつ実現するのでしょうか？
これはどのプラットフォーム（例えばアンドロイド）で実装されるのでしょうか？とは、いつ頃でしょうか？
awaiting ANSWER、ご指摘ありがとうございます。
Interesting:
私はその結論には反対です。OCO==「一方が他方を打ち消す」。まあ、MT5では、一方の注文が他方の注文をキャンセル するようなことはないんだけどね。1年前から後悔している。SLやTPなどの機能は、本当にオープンポジションをクローズしますが、保留中の注文を「キャンセル」する問題は、それとは全く関係ありません。
しかし、これらの命令はサーバー上で実行されます。そして、実際にOCOの仕組みに組み込まれているのは、今のところこれだけです（「If Done」命令をターミナルとサーバーに直接実装しようとは夢にも思っていません）。
MT5でポジションをオープンし、TPとSLを設定する場合、基本的に同じフォームを使用します（ただし、ここでの結果はポジション+2つのキャンセルされた注文です）。
メッセージの 後、私はすでにこの状況について、SLとTPが入れ替わってキャンセルされることを考慮に入れ、コメントしています。しかし、次のことを付け加えたいと思います。
もしOCO注文の作者が、21世紀には彼らの発明はSLとTPのレベルにしか適用されないと聞かされていたら、彼らの発明の適用範囲がこれほど制限されるのを見て、非常に驚いたことでしょう :) 。CCAオーダーは、MQL5のENUM_ORDER_TYPE列挙型で指定される交換可能なオーダーです。CCA注文とSL-TPレベルの関連性についての言及に出会ったことがない。つまり、実行メカニズムは同じでも、クライアントが実行するのはENUM_ORDER_TYPE命令であって、SL-TPレベルではない（MQによれば）。
ですから、私が保留中の注文について書いているときは、ENUM_ORDER_TYPEリストにある注文を意味し、SL-TPレベルに基づく「デリバティブ」注文ではありません。
______________
* OCO注文はそれぞれ異なるSL-TPレベルを持つことができるため、「デリバティブ」と呼ばれる。
皆さん、理解の根源はプラットフォームのシンプルさにあります。99％のユーザーにはシンプルに、残りの何％かのユーザーには理解できるような複雑さを意識的に拒否しています。
金融市場にX万人のユーザーを呼び込むには何が必要か」という問いを自分に投げかける。十分な経験を積めば、「シンプルなシステムを作り、複雑さを取り除き、トレーダーを一つのエコシステムに統合する」という答えに近くなるでしょう。
OCOの注文設定を積み重ねるのではなく（パネルは本当に普通の人の感覚ではありません）、SL/TPを統合した非常にシンプルで分かりやすい注文管理 方式を提供しました。OCO注文の大半は、現在のポジションのSL/TPに過ぎません。SL/TPをインサイドにすることで、追加注文を最小限に抑え、取引管理を大幅に簡素化することができました。
ps: 注文システムの問題は解決されました。
ps: 注文システムの問題は解決されました。
ps: 注文システムの問題は解決しました。
個別取引（トータルポジションではない）のSL/TPが普通に（確実に）作れなくなるのは残念です。
このため、同じ商品・口座で複数のストラテジーを（確実に）取引することができなくなります。
ハリボテは再開すべきではない、開発者の意見（1つの楽器＝1つのポジション＝1つのSLと1つのTP）を思い出した...。
ORDER_MAGICは 実際にはどの型(longまたはulong)に属しているのでしょうか？
enum_order_property_integer
ORDER_MAGIC
注文を出したExpert Advisorの識別子（各専門家が独自の番号を配置することを意図しています。）
長
ORDER_MAGICは 実際にはどの型(longまたはulong)に属しているのでしょうか？
enum_order_property_integer
ORDER_MAGIC
注文を出したExpert Advisorの識別子（各専門家が独自の番号を配置することを意図しています。）
長
私は、結果は、コードで宣言された型に変換されるべきだと思います（ドキュメントに誤植がある可能性があります）。
MqlTradeRequestについて言えば、この場合、（ulong）であることがほとんどです。
私見ですが、結果はコード内で宣言された型に変換されるはずです（ドキュメントに誤植があるかもしれません）。
MqlTradeRequestについては、この場合、(ulong)が最も可能性が高いですが、おそらくlongでも問題ないでしょう。
一般的には、答えは実力主義ではありません。質問は非常に明確で、"ORDER_MAGICは 実際には どの型（longまたはulong）に属しているのか？" というものでした。
本質的なことをやってみよう。
1.どちらの型も変換なしで宣言することができます。
2.magik を正の値でしか使わない場合は、ulong で指定したほうが得策です（0 から18 446 744 073 709 551 615 までが可能だからです）。
3.一方、Standard Libraryの CExpert クラスでは、初期化時にlong 値を適用する（負の値を指定できるが、指定可能な値の範囲がずれる）。そのため、このクラスを初期化する際に、magikの値はすでに -9 223 372 036 854 775 808から 9 223 372 036 854 775 808までと することが可能です。
この文は確認する必要が あります。
4.しかし、（同じ標準ライブラリの）CTrade クラスではすでに、クエリ構造に基づくべきものとして、マジシャンはulongという値を持っています。
予備的な結論を出しておこう。
a)CExpert クラスとCTrade クラスでmagikを使用する場合、前者ではlongが 指定され、後者ではulongが指定されるため、整合性がありません。
b) 問題のクラスが別の人によって開発された、あるいはCExpertの 特定の関数のパラメータのセットと構造がCTradeを 意識して書かれた（まだ存在しないかもしれない）。
c) 標準ライブラリの開発及び文書化に関連する専門家の作業は，完全に首尾一貫していない（ほとんどは，重要な問題についてのかなり良い研究が見られるが）。
d) 私の理解が正しければ、これら2つのクラスの相互作用によって、マジシャンの値は0から 9 223 372 036 854 775 808の 範囲に制限されます。この文は確認する必要が あります。
5.MqlTradeRequest 構造体は、magikと連携するためにulong型を持っています。全てはCTrade クラスと完全に一致します。だからこそ、このクラスだけを使うのであれば、magicianの取り得る値の範囲を0から 18 446 744 073 709 551 615まで 指定する方がより論理的なのです。この文は確認 する必要が あります。
追記
開発者は、マジシャンの値を0から 9までの 範囲で意図的に "締め "ていると思います。
開発者は、マジックの可能な値を0から 9の 範囲に意図的に「詰め込んだ」ようです223 372 036 854 775 808。
実は、マジックには8バイトもの情報が与えられていて、それをどう解釈してもいいんです。datetime、double、4short、8char、64bitをビット単位で指定することができる。
4の時は4バイトのマジックで何でもエンコードできましたが、今は8バイトです。必要なのは、意志だけです。