for(int i = 0; i < TransactionsTotal(); i++)
{
if(TransactionSelect(i, SELECT_BY_POS, MODE_TRADES))
{
ENUM_TRANS_TYPE trans_type = TransactionType();
if(trans_type == TRANS_HEDGE_POSITION)
{
if(HedgePositionGetInteger(HEDGE_POSITION_MAGIC) != myMagic)continue; // Работаем только со своими позициями.if(HedgePositionGetString(HEDGE_POSITION_SYMBOL) != Symbol())continue; // Работаем только с позициями на своем инструменте.double profit = HedgePositionGetDouble(HEDGE_POSITION_PROFIT_POINTS); //Профит в пунктахdouble currency = HedgePositionGetDouble(HEDGE_POSITION_PROFIT_CURRENCY); //Профит в валюте депозита.double price_open = HedgePositionGetDouble(HEDGE_POSITION_PRICE_OPEN); //Фактическая цена открытия позиции без клирингов и пр. изменений.double sl = HedgePositionGetDouble(HEDGE_POSITION_SL); //Узнаем уровень стоп-лосса позиции, если он есть, если нет - вернет нормализованный 0.0.if(HedgeOrderSelect(ORDER_SELECTED_INIT)) //Выбираем ордер, открывающий текущую позицию.
{
int deals = HedgeOrderGetInteger(HEDGE_ORDER_DEALS_TOTAL); //Получаем количество сделок, открывающего ордера.
}
// Ну и так далее...
}
}
}
...
しかし、私は注文を通してそれを実装 したかったのです（部分的に実行された注文が数日から3日間「立つ」ことが起こります）。
...
マイケル、君の言うとおりだ!なぜやらなかったの？ネットポジションを扱う場合、遅かれ早かれ、そこに含まれる注文を分析しないとやっていけないという事実に直面することを理解しなければなりません。これは、この問題を何ヶ月もかけて研究し、何度もこの間違いを犯してきた者としてお伝えすることです:)ましてや、複数の取引ロボットがある場合、それぞれのロボットの共同ポジションへの貢献度を考えなければならず、ここでもオーダーは欠かせません。必要な情報はすべて注文とそれに基づく取引に存在し、取引を1つのネットポジションにまとめると、逆にその情報が不可逆的に削除される。
しかし、注文や取引の分析に基づくシステムであれば、注文の 部分執行を 考慮する必要があります。そのためには、注文の仮想バージョンを作成し、新しい取引の到着を制御する必要があります。私のアルゴリズムは以下の通りです。
1.新しい案件を受信しました(カウンタHistoryDealsTotal()が変更されました)。
2.この取引がある注文によって開始された場合、一つの取引を含む新しい注文を作成する（COrder* order = new Order(deal) ）。
3.次に、既に存在する仮想オーダーの一覧から、同じ識別子を持つオーダーを探します。もしそのようなオーダーが見つかったら、作成されたオーダーの取引と見つかったオーダーの取引をマージしてそのプロパティを更新し、作成されたオーダーを削除する。同じ注文がまだリストにない場合は、単純にリストに追加します。
このようにして、システムは完全に決定論的となる。実際の注文が執行待ちであろうと、すでに履歴に移動していようと、私たちのシステムには常に実際に執行された数量で表示されるのです。
また、ポジションをクローズして、未約定部分が削除されないと、別のポジションをオープン（変更）するのでしょうか？
いい質問ですね。
注文が有効な場合、履歴に残らない（これは確実に確認済み）。
そしてもちろん、アクティブな注文は別のポジションを開くことができますが、もし
は再度部分的に実行されるため、ORDER_POSITION_IDは割り当てない。
つまり、ORDER_POSITION_IDは履歴でしか見る ことができない。
そうですね、株式市場ではそういうこともありますし、こういう状況も考慮しなければなりません。これは指値注文の基本的なデメリットの一つです。
あなたの例では、それを置き換えることができると思います。
へ。
すべての売買型取引は、何らかの注文によって開始されます。
いいえ、できません。なぜなら、取引は清算中に発生しますが、チケット（というかチケット＝0）を持っていないからです。
しかし、価格と種類（買い、売り）があり、もちろんINとOUTもある :(
ミハイル、そして正にその通り!なぜ実装していないのですか？ネットポジションを扱う場合、遅かれ早かれ、その中に含まれる注文の分析なしには成り立たないという事実に直面することを理解しなければなりません。これは、この問題を何ヶ月もかけて研究し、何度もこの間違いを犯してきた者としてお伝えすることです:)それに、複数の取引ロボットを持っている場合、トータルポジションで各ロボットの利益を考えなければならないので、ここでも注文は欠かせません。必要な情報はすべて注文とそれに基づく取引に含まれており、取引を単一のネットポジションにマッピングすることで、情報は不可逆的に削除されます。
しかし、注文や取引の分析に基づくシステムであれば、注文の 部分執行を 考慮する必要があります。そのためには、注文の仮想バージョンを作成し、新しい取引の到着を制御する必要があります。私のアルゴリズムは以下の通りです。
1.新しい案件を受信しました(カウンタHistoryDealsTotal()が変更されました)。
2.この取引がある注文によって開始された場合、一つの取引を含む新しい注文を作成する（COrder* order = new Order(deal) ）。
3.次に、既に存在する仮想オーダーの一覧から、同じ識別子を持つオーダーを探します。もしそのようなオーダーが見つかったら、作成されたオーダーの取引と見つかったオーダーの取引をマージしてそのプロパティを更新し、作成されたオーダーを削除する。同じ注文がまだリストにない場合は、単純にリストに追加します。
このようにして、システムは完全に決定論的となる。仮想注文の状態は新しい取引ごとに変化し、実際の注文が執行待ちであるか、すでに履歴に移動しているかは関係なく、システム上では常に実際に執行された数量で見ることができるのです。
問題解決、関係整理 )
関連する質問があります。
チケットで注文を選択して プロパティを見る場合、履歴やマーケットのどこにいてもチケットは変わらないので、とても不便です。
だから、こことあそこの両方で秩序を探さなくてはならないのです。
MT4のように、注文を選択すれば、その注文がどこにあるかは関係ない、とした方が簡単ではないでしょうか？
MT4ヘルプで読んだことがあります。
それについてどう思いますか？
P.S. Mihailは、これ以上新しいスレッドを作らないために、このスレッドを続けることを気にしないのでしょうか？
С-4さん、建設的な議論ができてとてもよかったです!
だから、（例えば1ヶ月後に）自分の利益を知るためには、ポジションの「正味」の値段が必要なんだ。
...
関数で(今使ってます)。
...
一般的にMetaTrader5のAPIは非常に低レベルであるため、関連する質問があります。でも ...取引所での取引は、複数の取引による注文の執行、マッチングされた取引をネットポジションにして清算を経て移管、豊富な委託取引など、様々なニュアンスを含んでいます。つまり、MetaTrader5 API（およびMT5自体）は、あらゆる取引所端末がそうであるべきように、そのようなものなのです。
もう一つは、そのAPIをMQL5で書かれた高水準のラッパーで包み、それを通してMT5の低水準の機能を利用できることである。もし私がラッパーを持っていたら、Mihailのタスクである利益計算は次のようになります。
いいえ、できません。トレードはクリアされていますが、チケットはありません（というかチケット＝0）。
が、価格と種類（BUYとSELL）、そしてもちろんINとOUTがあります :(
くそ、そうか。
それから、あなたにとっての悲しみ。
Vasiliy、私はすべてを実装しました（あなたのようにではありませんが、悪いことでもありません）、ただ、検索時間を短縮したかったのです。
いい質問ですね。
注文が有効な場合、履歴に残らない（これは確実に確認済み）。
そしてもちろん、アクティブな注文は別のポジションを開くことができますが、もし
は再度部分的に実行されるため、ORDER_POSITION_IDは割り当てない。
つまり、ORDER_POSITION_IDは履歴でしか見る ことができない。
ところで、ロボットの多方向入力にはどのように対処していますか？結局のところ、あるExpert Advisorの市場への参入は、他のロボットのポジションからの退出かもしれないのです。
ここでは問題が違うのです。この注文の約定した取引の一部は、あるポジションに属し、他の一部はすでに別の新しいポジションに属します。そうすると、いずれ履歴に残るときに、どのようなポジションIDを割り当てるかが問題になります。
完全に満たされた注文は、その注文がオープンまたは変更されたポジションのIDを受け取ります。
ただし、これは履歴にしか残らない（ID）。