Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Одновременно может быть >=2 тейков и стопов?
Да, верно. Мы выполнили первичный вход, выставили ТП и стоп ордера. Потом через время могла произойти доливка, и выставиться еще ТП и стоп ордера.
Я на случай потери события запоминаю выставленные ордера, тикет последней учтённой сделки, время последней записи (изменения) состояния, и периодически, а также при ините, синхронизирую список ордеров и проверяю наличие неучтённых сделок.
Приход событий в случайном порядке - норма, отсутствие (временное) ордера и в ордерах и в истории - не редкость, может возникать как до, так и после появления сделки.
Позиция при неттинге получает тикет первого ордера и при дальнейших сделках(изменениях) его сохраняет, пока не закрывается (т.е., становится 0.0).
Ну и, в зависимости от объёма ордера, он может породить несколько сделок.Поделитесь опытом и идеями пожалуйста.
Вы изначально не правильно всё делаете.
Зачем магики и всякие проверки?
Тикет (билет) ордера - уникальный идентификатор.
Если Вы отсылаете синхронный ордер, то получаете тикет в результате выполнения функции.
Если же ассинхронная отправка ордера, то тикет получаем в OnTradeTransaction
Добавлено
А здесь https://www.mql5.com/ru/forum/67298/page2#comment_2089220
хорошая функция для проверки ордера
Да, верно. Мы выполнили первичный вход, выставили ТП и стоп ордера. Потом через время могла произойти доливка, и выставиться еще ТП и стоп ордера.
Сами лимитники, для которых нужны будут TP/SL, могут исполняться частично. При этом и TP в виде лимитников - аналогично. Например, TP исполнился на треть объема - надо SL на столько же уменьшать.
В общем, довольно неприятная логика для отлова всех приколов.
ЗЫ Задачу бы реализовал в OnTrade. Сложно не должно было бы получиться.
Вы изначально не правильно всё делаете.
Зачем магики и всякие проверки?
Тикет (билет) ордера - уникальный идентификатор.
Если Вы отсылаете синхронный ордер, то получаете тикет в результате выполнения функции.
Если же ассинхронная отправка ордера, то тикет получаем в OnTradeTransaction
Добавлено
А здесь https://www.mql5.com/ru/forum/67298/page2#comment_2089220
хорошая функция для проверки ордера
Я на случай потери события запоминаю выставленные ордера, тикет последней учтённой сделки, время последней записи (изменения) состояния, и периодически, а также при ините, синхронизирую список ордеров и проверяю наличие неучтённых сделок.
Приход событий в случайном порядке - норма, отсутствие (временное) ордера и в ордерах и в истории - не редкость, может возникать как до, так и после появления сделки.
Позиция при неттинге получает тикет первого ордера и при дальнейших сделках(изменениях) его сохраняет, пока не закрывается (т.е., становится 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
События сделок (TRADE_TRANSACTION_DEAL_ADD) по несколько раз регулярно приходят.
К счастью повторяется только самая последняя (во всяком случае не ловил приход более старых).
Чтобы фильтровать достаточно проверять не совпадает ли тикет сделки с предыдущим.
События сделок (TRADE_TRANSACTION_DEAL_ADD) по несколько раз регулярно приходят.
К счастью повторяется только самая последняя (во всяком случае не ловил приход более старых).
Чтобы фильтровать достаточно проверять не совпадает ли тикет сделки с предыдущим.
Не по несколько раз, а по кол-ву советников, в данный момент работающих в терминале.
Поэтому каждый советник должен обрабатывать свой ордер
Не по несколько раз, а по кол-ву советников, в данный момент работающих в терминале.
Поэтому каждый советник должен обрабатывать свой ордер
Ваш код защищает от того, что это была сделка этого советника.
Я и ТС говорят о случаях, когда OnTradeTransaction с типом TRADE_TRANSACTION_DEAL_ADD вызывается несколько раз по одной сделке, т.е. в остальных полях MqlTradeTransaction точно такие же данные.
То есть в вашем случае код обработки может быть исполнен несколько раз.
Возможно, что это бывает не у всех брокеров. Но у всех биржевых, с которыми я работал такое бывает регулярно.
Ваш код защищает от того, что это была сделка этого советника.
Я и ТС говорят о случаях, когда OnTradeTransaction с типом TRADE_TRANSACTION_DEAL_ADD вызывается несколько раз по одной сделке, т.е. в остальных полях MqlTradeTransaction точно такие же данные.
То есть в вашем случае код обработки может быть исполнен несколько раз.
Возможно, что это бывает не у всех брокеров. Но у всех биржевых, с которыми я работал такое бывает регулярно.
Я торгую в Открывашке на реале и тестирую на демо, но у меня нет многоразовых срабатываний.
Выложите Ваш кусок кода для TRADE_TRANSACTION_DEAL_ADD
События сделок (TRADE_TRANSACTION_DEAL_ADD) по несколько раз регулярно приходят.
К счастью повторяется только самая последняя (во всяком случае не ловил приход более старых).
Чтобы фильтровать достаточно проверять не совпадает ли тикет сделки с предыдущим.
Да, спасибо! Как раз так и сделал после увиденного.
По первоначальной проблеме поставил слип , чтобы успевали прокачиваться транзакции удаления ордера и добавления в историю. Наблюдаю.
Несовершенство платформы в этом отношении очень печалит. Вещи, которые должны быть в связке, делают отдельными.
Не по несколько раз, а по кол-ву советников, в данный момент работающих в терминале.
Поэтому каждый советник должен обрабатывать свой ордер