Вопрос о функции OnTradeTransaction - страница 17

[JRandomTrader]

Alexey Viktorov #:

Я про TRADE_TRANSACTION_ORDER_ADD - когда впервые появляется тикет ордера. Ещё нет сделки, ещё даже нет TRADE_TRANSACTION_REQUEST, где этот ордер выставляется.

Это актуально при асинхронной отправке отложенных ордеров.

При этом в первом TRADE_TRANSACTION_REQUEST (отправка) нет тикета ордера, а во втором TRADE_TRANSACTION_REQUEST, где ответ, тоже нет Magic'а, есть только ReqID, совпадающий с ReqID первого TRADE_TRANSACTION_REQUEST. И это единственная возможность привязать действующий ордер к Magic'у.

Если по какой-то причине(ребут, BSOD) пропустили второй TRADE_TRANSACTION_REQUEST - остаётся только гадать(по символу, цене и времени), какой именно робот выставил этот ордер.

[JRandomTrader]

С момента запуска 8 сделок по 4 ордерам - пока задвоений TRADE_TRANSACTION_DEAL_ADD не обнаружено.

Но я сейчас торгую только рыночными ордерами. Да, комиссия больше, но суммарная прибыль её в разы перекрывает.

[Andrey Kaunov]

Ключевой фактор, когда ордер срабатывает по частям, но одновременно. Обратите внимание на таймкод в логе.

[Alexey Viktorov]

JRandomTrader #:

Я про TRADE_TRANSACTION_ORDER_ADD - когда впервые появляется тикет ордера. Ещё нет сделки, ещё даже нет TRADE_TRANSACTION_REQUEST, где этот ордер выставляется.

Это актуально при асинхронной отправке отложенных ордеров.

При этом в первом TRADE_TRANSACTION_REQUEST (отправка) нет тикета ордера, а во втором TRADE_TRANSACTION_REQUEST, где ответ, тоже нет Magic'а, есть только ReqID, совпадающий с ReqID первого TRADE_TRANSACTION_REQUEST. И это единственная возможность привязать действующий ордер к Magic'у.

Если по какой-то причине(ребут, BSOD) пропустили второй TRADE_TRANSACTION_REQUEST - остаётся только гадать(по символу, цене и времени), какой именно робот выставил этот ордер.

Точно так-же

  if(trans.type == TRADE_TRANSACTION_ORDER_ADD)
   {
    if(OrderSelect(trans.order))
     {
      printf("Magic ордера: %I64u", OrderGetInteger(ORDER_MAGIC));
      printf("order - тикет ордера: %I64u", OrderGetInteger(ORDER_TICKET));
     }
   }

2023.03.28 16:25:26.676 eOnTradeTransactionTest (SBPR-6.23,M1)  type - тип торговой транзакции: TRADE_TRANSACTION_ORDER_ADD
2023.03.28 16:25:33.484 eOnTradeTransactionTest (SBPR-6.23,M1)  Magic ордера: 12
2023.03.28 16:25:34.037 eOnTradeTransactionTest (SBPR-6.23,M1)  order - тикет ордера: 830931705

[Alexey Viktorov]

Andrey Kaunov #:
Ключевой фактор, когда ордер срабатывает по частям.

Да, ключевой фактор исполнение по частям. Даже если по частям происходит установка ордера, то так-же TRADE_TRANSACTION_DEAL_ADD задваивается.

[Alexey Viktorov]

JRandomTrader #:

TRADE_TRANSACTION_ORDER_UPDATE может появляться несколько раз - при изменении статуса ордера или при модификации, это нормально.

Что кроме статуса ордера может вызвать транзакцию TRADE_TRANSACTION_ORDER_UPDATE

Никакой модификации не делается. Только постановка лимитника скриптом.

2023.03.28 16:25:41.572 eOnTradeTransactionTest (SBPR-6.23,M1)  type - тип торговой транзакции: TRADE_TRANSACTION_ORDER_UPDATE
2023.03.28 16:25:42.852 eOnTradeTransactionTest (SBPR-6.23,M1)  Статус ордера: ORDER_STATE_PLACED
2023.03.28 16:25:44.142 eOnTradeTransactionTest (SBPR-6.23,M1)  type - тип торговой транзакции: TRADE_TRANSACTION_ORDER_UPDATE
2023.03.28 16:25:45.415 eOnTradeTransactionTest (SBPR-6.23,M1)  Статус ордера: ORDER_STATE_PLACED
2023.03.28 16:25:47.069 eOnTradeTransactionTest (SBPR-6.23,M1)  type - тип торговой транзакции: TRADE_TRANSACTION_REQUEST
2023.03.28 16:26:08.697 eOnTradeTransactionTest (SBPR-6.23,M1)  type - тип торговой транзакции: TRADE_TRANSACTION_ORDER_UPDATE
2023.03.28 16:26:08.697 eOnTradeTransactionTest (SBPR-6.23,M1)  Статус ордера: ORDER_STATE_REQUEST_CANCEL
2023.03.28 16:26:08.697 eOnTradeTransactionTest (SBPR-6.23,M1)  type - тип торговой транзакции: TRADE_TRANSACTION_REQUEST
2023.03.28 16:26:08.697 eOnTradeTransactionTest (SBPR-6.23,M1)  type - тип торговой транзакции: TRADE_TRANSACTION_ORDER_UPDATE
2023.03.28 16:26:08.697 eOnTradeTransactionTest (SBPR-6.23,M1)  Статус ордера: ORDER_STATE_REQUEST_CANCEL

[JRandomTrader]

Andrey Kaunov #:
Ключевой фактор, когда ордер срабатывает по частям, но одновременно. Обратите внимание на таймкод в логе.

У меня прошло 8 сделок по 4 ордерам. Два ордера вызвали по одной сделке, а другие два - по три сделки. Пока задвоение не выявлено.

Ордера рыночные, должно бы проходить одновременно, но миллисекунды сделок не совпадают.

Возможно, третье условие (кроме по частям, но одновременно) - ордер лимитный.

[JRandomTrader]

Alexey Viktorov #:

Что кроме статуса ордера может вызвать транзакцию TRADE_TRANSACTION_ORDER_UPDATE

Никакой модификации не делается. Только постановка лимитника скриптом.

Могу предположить, что ордер последовательно прошёл статусы

ORDER_STATE_STARTED

ORDER_STATE_REQUEST_ADD

ORDER_STATE_PLACED

ORDER_STATE_REQUEST_CANCEL

некоторые из них - очень быстро, что не удаётся отловить.

Не забываем, что всё асинхронно, и статус ордера, который получаем мы, может отличаться от того, который был в момент возникновения события TRADE_TRANSACTION.

Бывает также ситуация, когда ордер уже не находится в действующих и ещё не находится в истории.

[Andrey Kaunov]

JRandomTrader #:

У меня прошло 8 сделок по 4 ордерам. Два ордера вызвали по одной сделке, а другие два - по три сделки. Пока задвоение не выявлено.

Ордера рыночные, должно бы проходить одновременно, но миллисекунды сделок не совпадают.

Возможно, третье условие (кроме по частям, но одновременно) - ордер лимитный.

В последнем примере у меня при закрытии по рынку было задвоение. Совершенно не обязательно должен быть лимитник. Но, вероятно, на нём чаще всего встречается.

Еще, у меня демо счёт.

[Dmi3]

JRandomTrader #:

Не помню авторства цитаты, но: "Все мы в этой жизни бета-тестеры".

И, в данном случае наш профит не в зарплате, а в более правильной работе MT.

Профит трейдера обычно состоит в том, чтобы найти баг (неэффективность), понять как его обойти (использовать) и никому не сказав об этом наживаться на ошибках других :)