Обработка транзакций OnTradeTransaction - страница 2

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
Ilya Rebenok
310
Ilya Rebenok  
fxsaber:

Одновременно может быть >=2 тейков и стопов?

Да, верно.  Мы выполнили первичный вход, выставили ТП и стоп ордера. Потом через время могла произойти доливка, и выставиться еще ТП и стоп ордера.

JRandomTrader
44
JRandomTrader  

Я на случай потери события запоминаю выставленные ордера, тикет последней учтённой сделки, время последней записи (изменения) состояния, и периодически, а также при ините, синхронизирую список ордеров и проверяю наличие неучтённых сделок.

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

Позиция при неттинге получает тикет первого ордера и при дальнейших сделках(изменениях) его сохраняет, пока не закрывается (т.е., становится 0.0).

Ну и, в зависимости от объёма ордера, он может породить несколько сделок.
prostotrader
8021
prostotrader  
Илья Ребенок:


Поделитесь опытом и идеями пожалуйста.

Вы изначально не правильно всё делаете.

Зачем магики и всякие проверки?

Тикет (билет) ордера - уникальный идентификатор.

Если Вы отсылаете синхронный ордер, то получаете тикет в результате выполнения функции.

Если же ассинхронная отправка ордера, то тикет получаем в OnTradeTransaction

Добавлено

А здесь https://www.mql5.com/ru/forum/67298/page2#comment_2089220

хорошая функция для проверки ордера

ФОРТС: В помощь начинающим
ФОРТС: В помощь начинающим
  • 2015.11.25
  • www.mql5.com
Установка отложенного ордера командой OrderSend().
fxsaber
16703
fxsaber  
Илья Ребенок:

Да, верно.  Мы выполнили первичный вход, выставили ТП и стоп ордера. Потом через время могла произойти доливка, и выставиться еще ТП и стоп ордера.

Сами лимитники, для которых нужны будут TP/SL, могут исполняться частично. При этом и TP в виде лимитников - аналогично. Например, TP исполнился на треть объема - надо SL на столько же уменьшать.

В общем, довольно неприятная логика для отлова всех приколов.


ЗЫ Задачу бы реализовал в OnTrade. Сложно не должно было бы получиться.

Ilya Rebenok
310
Ilya Rebenok  
prostotrader:

Вы изначально не правильно всё делаете.

Зачем магики и всякие проверки?

Тикет (билет) ордера - уникальный идентификатор.

Если Вы отсылаете синхронный ордер, то получаете тикет в результате выполнения функции.

Если же ассинхронная отправка ордера, то тикет получаем в OnTradeTransaction

Добавлено

А здесь https://www.mql5.com/ru/forum/67298/page2#comment_2089220

хорошая функция для проверки ордера

Спасибо, почитаю.
JRandomTrader:

Я на случай потери события запоминаю выставленные ордера, тикет последней учтённой сделки, время последней записи (изменения) состояния, и периодически, а также при ините, синхронизирую список ордеров и проверяю наличие неучтённых сделок.

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

Позиция при неттинге получает тикет первого ордера и при дальнейших сделках(изменениях) его сохраняет, пока не закрывается (т.е., становится 0.0).

Ну и, в зависимости от объёма ордера, он может породить несколько сделок.

Одна из целей робота была уйти от локальной зависимости. То есть получать данные только от рынка, без привязки к переменных терминала ил ПК. То есть, чтобы в случае срочной необходимости перейти на другой ПК и робот все подхватил.

Сейчас еще интересный баг увидел. Пришло 2 одинаковых транзакции TRADE_TRANSACTION_DEAL_ADD. Что за херня, простите?) В итоге робот на 1 сделку выставил 2 раза стопы.

2019.02.08 10:55:29 [INFO]: ( PChBreak_RTS-3.19_22) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEAL_ADD
Symbol: RTS-3.19
Deal ticket: 12674810
Deal type: DEAL_TYPE_BUY
Order ticket: 82646001
Order type: ORDER_TYPE_BUY
Order state: ORDER_STATE_STARTED
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01.01 00:00
Price: 119700
Price trigger: 0
Stop Loss: 0
Take Profit: 0
Volume: 1
Position: 82646001
Position by: 0

2019.02.08 10:55:32 [INFO]: ( PChBreak_RTS-3.19_22) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEAL_ADD
Symbol: RTS-3.19
Deal ticket: 12674810
Deal type: DEAL_TYPE_BUY
Order ticket: 82646001
Order type: ORDER_TYPE_BUY
Order state: ORDER_STATE_STARTED
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01.01 00:00
Price: 119700
Price trigger: 0
Stop Loss: 0
Take Profit: 0
Volume: 1
Position: 82646001
Position by: 0

Ilya Baranov
4315
Ilya Baranov  

События сделок (TRADE_TRANSACTION_DEAL_ADD) по несколько раз регулярно приходят.

К счастью повторяется только самая последняя (во всяком случае не ловил приход более старых).

Чтобы фильтровать достаточно проверять не совпадает ли тикет сделки с предыдущим.

prostotrader
8021
prostotrader  
Ilya Baranov:

События сделок (TRADE_TRANSACTION_DEAL_ADD) по несколько раз регулярно приходят.

К счастью повторяется только самая последняя (во всяком случае не ловил приход более старых).

Чтобы фильтровать достаточно проверять не совпадает ли тикет сделки с предыдущим.

Не по несколько раз, а по кол-ву советников, в данный момент работающих в терминале.

Поэтому каждый советник должен обрабатывать свой ордер

case TRADE_TRANSACTION_DEAL_ADD:
      if((BuyOrder.ticket > 0) && (trans.order == BuyOrder.ticket))  // Buy order
      {
        //Сделка этого советника
      }
break;
Ilya Baranov
4315
Ilya Baranov  
prostotrader:

Не по несколько раз, а по кол-ву советников, в данный момент работающих в терминале.

Поэтому каждый советник должен обрабатывать свой ордер

Ваш код защищает от того, что это была сделка этого советника.

Я и ТС говорят о случаях, когда OnTradeTransaction с типом TRADE_TRANSACTION_DEAL_ADD вызывается несколько раз по одной сделке, т.е. в остальных полях MqlTradeTransaction точно такие же данные.

То есть в вашем случае код обработки может быть исполнен несколько раз.

Возможно, что это бывает не у всех брокеров. Но у всех биржевых, с которыми я работал такое бывает регулярно.

prostotrader
8021
prostotrader  
Ilya Baranov:

Ваш код защищает от того, что это была сделка этого советника.

Я и ТС говорят о случаях, когда OnTradeTransaction с типом TRADE_TRANSACTION_DEAL_ADD вызывается несколько раз по одной сделке, т.е. в остальных полях MqlTradeTransaction точно такие же данные.

То есть в вашем случае код обработки может быть исполнен несколько раз.

Возможно, что это бывает не у всех брокеров. Но у всех биржевых, с которыми я работал такое бывает регулярно.

Я торгую в Открывашке на реале и тестирую на демо, но у меня нет многоразовых срабатываний.

Выложите Ваш кусок кода для TRADE_TRANSACTION_DEAL_ADD

Ilya Rebenok
310
Ilya Rebenok  
Ilya Baranov:

События сделок (TRADE_TRANSACTION_DEAL_ADD) по несколько раз регулярно приходят.

К счастью повторяется только самая последняя (во всяком случае не ловил приход более старых).

Чтобы фильтровать достаточно проверять не совпадает ли тикет сделки с предыдущим.

Да, спасибо! Как раз так и сделал после увиденного.

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

Несовершенство платформы в этом отношении очень печалит. Вещи, которые должны быть в связке, делают отдельными.

prostotrader:

Не по несколько раз, а по кол-ву советников, в данный момент работающих в терминале.

Поэтому каждый советник должен обрабатывать свой ордер

в этом случае мне все равно где-то нужно хранить тикет ордера из реквеста, чтобы потом сравнивать его с тикетом из сделки. А я как раз хочу уйти от всех хранений в локальных переменных и получать инфо исключительно от рынка/терминала, чтобы нивелировать локальные инфраструктурные риски.
Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий