Решение данной проблемы видится так: вводится связь (FILL->KILL) на уровне торгового сервера MT5 между Limit-ордерами и Stop-ордерами, которая дает следующее: - перед тем, как сделать маркет-сиполнение Stop-ордера, удаляется Execution-сервером связанный с ним Limit-ордер. - после срабатывания Limit-ордера, удаляется Execution-сервером связанный с ним Stop-ордер.
いろいろな場面で大胆な主張（私の資質、三菱商事の状況など）をされているので、あなたの意見に対する興味がやや薄れるのではないでしょうか))なんとなく返信する意味がないんだよなー、明らかに不備のある人の発言になんで反応するんだろう。)))
手始めに、幻覚と現実を混同するのをやめましょう - 話し合いましょう。
以上、落ち着きました。
何を話そうか？
すでにペンとノートを用意しています。
>> お話を伺っております。
ただ、明確にした。SL レベルはいかなる保証もなく、Market request によってのみ市場で執行されるため、TP レベルを打たないという義務は不要である。マーケットでSLを実行する直前に、Execution-server（Dukascopy）はTPレベルを削除します（たとえそれがpickにあったとしても）。この点は、残念ながらMT5では、たとえトレードサーバーに完璧に接続できたとしても、トレーダーが希望的に実施できない点です。そして、それは、確かに、MT5では本当に不可能なことです。
この問題を解決するために、私たちはこう考えています。
MT5トレーディングサーバーレベルで、LimitオーダーとStopオーダーの間にリンク（FILL->KILL）が導入され、以下のようになります。
- 成行ストップ注文を出す前に、執行サーバーはそれに関連する指値注文を削除します。
- 指値注文がトリガーされると、執行サーバーはその指値注文に関連する逆指値注文を削除し ます。
これらの問題は、サーバーに条件付注文を導入することで簡単に解決することができます。ちなみに、これは古典的な為替スキームに従って動いている多くのブローカーで行われていることである。このため、注文を設定する際に、連動する注文をキャンセルして入力するように設定する可能性を追加する必要があります。Aの注文が実行されれば、BとCの注文が入るという初歩的なロジックである。キャンセルも同様で、Aの注文が成立すると、BとCはキャンセルされます。またはその逆で、注文Aが約定に至った場合、注文Bはキャンセルされます。そして、集計位置の計算の問題や、TPやSLの設定・解除の問題など、初歩的な問題を解決します。さらに、さまざまな可能性を与えてくれます。
Z.U.さん 書き込んだ後、getchさんが以前に記事で紹介されているのを拝見しました。ただ、指値と逆指値の 注文だけは接続する必要がない。もし、どれかがリンクしていれば、もっと多くの可能性があります。
対象：ゲッチュ
Решение данной проблемы видится так:
вводится связь (FILL->KILL) на уровне торгового сервера MT5 между Limit-ордерами и Stop-ордерами, которая дает следующее:
- перед тем, как сделать маркет-сиполнение Stop-ордера, удаляется Execution-сервером связанный с ним Limit-ордер.
- после срабатывания Limit-ордера, удаляется Execution-сервером связанный с ним Stop-ордер.
これは、オーダーに異なるチケットがあるため、難しいのです。
サーバーと端末でもう1項目入力する必要があります。
と、MQはそんな非標準的な動きに出ることはない。
TPとSLが存在する。では、集合体としての位置づけであればどうでしょう。
インテージャーが言ったように、ストップは最後の手段です :-)
アヴァルスに。
このトピックは、どのように、それができるのか、ということでは全くありません。
できるのです。
このトピックでは、複数のEAと1つの集約されたポジションでの注文執行の信頼性について説明します。
これは、最も信頼性の高いオプションではありません。
宛先：ゲッチ
これは、オーダーが異なるチケットを持っているため、難しいのです。
サーバーと端末でもう1つフィールドを入力する必要があります。
と、MQはそんな非標準的な動きに出ることはない。
TPとSLが存在する。では、集合体としての位置づけであればどうでしょう。
インテージャーが言ったように、ストップは最後の手段です :-)
MQとSLはgetch)))と同じで、100％信頼性が高く、ほとんどの証券会社のソフトウェアに実装されている標準的なステップです。
これらの問題は、サーバーに条件付注文を導入することで簡単に解決することができます。ちなみに、これは古典的な為替スキームに従って動いている多くのブローカーで行われていることである。このため、注文を設定する際に、連動する注文をキャンセルして入力するように設定する可能性を追加する必要があります。Aの注文が実行されれば、BとCの注文が入るという初歩的なロジックである。キャンセルも同様で、Aの注文が成立すると、BとCはキャンセルされます。またはその逆で、注文Aが約定に至った場合、注文Bはキャンセルされます。そして、集計位置の計算の問題や、TPやSLの設定・解除の問題など、初歩的な問題を解決します。さらに、さまざまな可能性を与えてくれます。
Z.U.さん 書き込んだ後、getchさんが以前に記事で紹介されているのを拝見しました。ただし、指値注文と逆指値注文だけを接続する必要はない。どれかをリンクさせれば、もっと幅が広がります。
私が悪いのですが、理解できていません。となっています。ミニスクリプトのようなもの。
しかし、問題は、非累積項目を保存するよりもさらにサーバーに大きな負荷がかかるということです。
私が悪かった、うまくいかなかったんだ。それはいい考えですね。ミニスクリプトのようなものです。
しかし、問題は、非累積項目を保存するよりもさらにサーバーに大きな負荷がかかるということです。
だから、ユーザーはこれらの要求をそのまま入力することになる。実際、すべてが初歩的で、リソースを消費することはありません。どんなプラットフォームにも必要なものです。例えば、QUIKaは、http://www.quik.ru/about/features/conditional-orders/。
Alpha-Directにはhttp://www.alfadirect.ru/help3_3/index.htm、 他のブルジョア取引プラットフォームにはあります。搭載していない端末は記憶にありません。
私はgetch)))と同じように書きましたが、ほとんどの証券会社のソフトウェアに実装されている100％信頼できる標準的なステップです。
より多くの可能性は、一般的なOCO-order（取引サーバー上の最も原始的なミニスクリプト）により与えられます。MT5のFILL->KILLフラグで十分なようです。一部の企業（StrategyRunner）は、スクリプトやExpert Advisorまでサーバーに保存する方法を選択しています。この方法には、メリット（議論の余地あり）とデメリット（議論の余地あり）があります。MetaQuotesは別の道を歩んでいます。
一般的なOCO-order（トレードサーバー上の原始的なミニスクリプト）により、より多くの機会が提供されます。MT5のFILL->KILLフラグで十分なようです。一部の企業（StrategyRunner）は、スクリプトやExpert Advisorまでサーバーに保存する方法を選択しています。この方法には、メリット（議論の余地あり）とデメリット（議論の余地あり）があります。MetaQuotesは別の道を歩んでいます。
彼らがどのような道を選んだのかは、まだよくわからないが)))