Бред. Какая связь между кэшем, где сохраняются данные о запрашиваемой позиции, и транзакциями?
prostotrader, у Вас там с логикой алгоритма наверное что-то не то. Хотел было покопаться в чужом коде, но влом... потом тип исполнения тут:
request.type_filling=ORDER_FILLING_IOC; // разве так?
request.type_filling=ORDER_FILLING_RETURN; // а может так?
И вообще в каких университетах так учат кодировать?
カルプトフ・ウラジミール OnTradeTransaction() の簡略化 - 取引履歴の追加のみを考慮 - 注文なし
大丈夫です、わざわざ書かなくても（時間を無駄にしないで）。
実機がクラッシュするので調べ始めたんです。
週末にサーバーをアップグレードしたようです。ミリ秒が出た。もっとサプライズがあるかもしれません。
どうやら、OnTradeTransaction 関数は、トランザクションログとは独立して動作するようです。
私は、この関数の動作は合理的だと思います。操作の流れを遅くして、ログが書き込まれ、すべてが計算されるまで待つ必要はないのです。
あなたの場合、OnTradeを 使った方がいいかもしれませんね。
または待機し、履歴に案件が表示されたら最小限の休止で定期的に確認します。
週末にサーバーをアップグレードしたようです。ミリ秒が表示されました。もっとサプライズがあるかもしれません。
OnTradeTransaction 関数は、操作ログとは独立して動作するようです。
私は、この関数の動作は正当だと思います。操作の流れを遅くして、すべてがジャーナルに登録されカウントされるまで待つ必要はありません。
あなたの場合、OnTradeを 使うのがよいでしょう。
または待機し、履歴に案件が表示されたら最小限の休止で定期的に確認します。
セルゲイさん、こんにちは。
しかし、週末ではなく、木曜日のイブニングセッションの後に行いました（私のブローカーに聞きました）。
Trade()イベントを使用して、ターミナルでデータが更新されるのを待つことができない。
Expert Advisor はかなり前に作成され、最近まで「時計仕掛けのように」動作していました（運が良かったのか、TRADE_TRANSACTION_DEAL_ADD イベントは常に最初に 到着していました）。
Expert Advisorにとって、相互売買をできるだけ早く実行することが重要であり、そのために非同期モードとOnTradeTransaction()が使用されています。
現在、Expert Advisorは（時々）ポジションの オープンとクローズの ために重複した注文を送信しています。
あなた：「この関数の動作は正当だと思います。 操作の流れを遅くして、すべてがジャーナルに書き込まれカウントされるのを待つ必要はないのです」。
とにかく、TRADE_TRANSACTION_DEAL_ADDが 到着した後に、すべてが書き込まれ、カウントされます:)
TRADE_TRANSACTION_DEAL_ADDが失われ、TRADE_TRANSACTION_HISTORY_ADDが来て、端末が古い位置データを持って しまう可能性が あることです。:(,
ということが実際に起こります。
開発者が考えなかったことが不思議なくらいです。
TRADE_TRANSACTION_HISTORY_ADDは、注文が約定または削除（キャンセル）された場合にのみ発生します。
注文状態が変化した場合（それぞれ、位置が変化する可能性がある）、端末は位置の変化に関する情報を受信する必要があります。
TRADE_TRANSACTION_DEAL_ADDが失わ れたとしても
それでは、開発者のコメントをご覧ください。
カルプトフ・ウラジミール OnTradeTransaction()の簡略化 - 取引履歴の追加のみを考慮 - 注文なし
大丈夫です、わざわざ書かなくても（時間を無駄にしないで）。
先生」「知ったかぶり」に中身のある発言をお願いします。
そして、自分の主張をするために、ポールに足をかけるだけではありません。
助けてほしい人にアピールする前に、普通に質問を練ってください。OrderSend()関数で 部分決済を行う場合、注文の非同期送信はどのような関係があるのでしょうか？何について質問しているのですか？
素晴らしい
それはヘルプと見るべきでしょうか？
それにカルプトフは関係ないですよ、私が書き込みをした時に彼はもう書き込みをしていて、私はそれを見ていなかっただけです。
当初、次のような質問があった（最初に読むのが面倒な人のために念のため）。
開発者にエラーを表示するためのログを構築するには？
なぜかというと、自分でやってみたところ、ログにはっきりと次のようなことが書かれていたからです。
TRADE_TRANSACTION_HISTORY_ADDの 後（TRADE_TRANSACTION_DEAL_ADDの前）。
の場合、端末は位置情報を更新しない。
prostotrader さん、Dimitriさんは、あなたのコードでは部分（および完全）クロージャは非同期ではなく、同期であると正しく伝えていますね...。これは、プログラムがサーバーからの応答を待っていることを意味します。
ポジションそのものが変化するよりも、OnTradeTransaction が速くトリガーされる可能性があります。
では、ここで。
ポジションチェックをループさせてみてはいかがでしょうか。もしかしたら、役に立つかもしれない...。
こんな感じです。
正確なアルゴリズム（ プログラムから必要とされるもの）がわからないと、その実装の正しさを評価するのは難しいのですが......。
完全に非同期モードに変更されました
しかし、何も変わっていません
当たり前のことですが、実験の「純粋さのために」...
地下室の完全なログ
1.>正確なアルゴリズム（プログラムから必要とされるもの）がわからないと、正しく実装されているか どうか評価するのは難しいのですが......。
プログラムが何をするのか理解するのは難しくないと思っていましたが、もし明確でないのなら
Expert Advisor が FORTS 市場で 2 単位のポジションを建てた場合、1 単位の数量で部分的に決済されます。
にすると、ポジションが完全に閉じられます。カウンタtr_cnt<50になるまでこの手順を繰り返す
2.PositionSelect() を100万回実行しても、何も変わりません。
ループに入るまでTRADE_TRANSACTION_DEAL_ADDイベントを受信しないため、端末が更新されない。
位置情報
...
上にも書きましたが、注文に流されず、取引を見ることです。以下は、ポジション量が変化するタイミングと、それがどのような種類の取引 であるかを示す短いコードです。
そしてこちらが、一部クロージング時のプリントです。
TRADE_TRANSACTION_DEAL_ADD という取引種別のイベントが通過すると、それだけで端末のポジションデータが更新されるのがよくわかりますね。