Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ничего вы не поняли. Когда делаем return, то заходим в On-функции сформированной очереди. Это может вызвать паузу, которая не даст СРАЗУ после первого OrderSend послать правильный второй.
А в чем пауза\задержка? В копировании 3х структур?
Вы же предлагаете накопить очередь через сохранение всех On-функций после return, дождавшись On-функцию, в которой будет сообщение о завершении первого OrderSend. И тогда только отправлять второй OrderSend.
Накапливать все события не обязательно. Не ждите копирования следующее события - можно обрабатывать события и до return и отправлять второй OrderSend как только для этого возникнут предпосылки
При этом еще и не понимаете, что тейк позиции может исполниться во время первого OrderSend, но его OnTradeTransaction будет в очереди позже (в ту же микросекунду, но позже), чем завершающий OnTradeTransaction от первого OrderSend.
А как Вам в такой ситуации поможет?
bool HandleNextEvent(ENUM_EVENT_TYPE);
Оно что здесь будет последним, что там
Ничего вы не поняли. Когда делаем return, то заходим в On-функции сформированной очереди. Это может вызвать паузу, которая не даст СРАЗУ после первого OrderSend послать правильный второй.
Вы же предлагаете накопить очередь через сохранение всех On-функций после return, дождавшись On-функцию, в которой будет сообщение о завершении первого OrderSend. И тогда только отправлять второй OrderSend.
При этом еще и не понимаете, что тейк позиции может исполниться во время первого OrderSend, но его OnTradeTransaction будет в очереди позже (в ту же микросекунду, но позже), чем завершающий OnTradeTransaction от первого OrderSend.
Нет никакой очереди. Новое событие будет обрабатываться после текущего, а все произошедшие в этот период события будут проигнорированы.
На мой взгляд, решением проблемы стала бы возможность "подписаться" на какой-либо ордер. Т.е. чтобы терминал генерировал событие по возникновению какой-либо сделки по ордеру.
Но это должны реализовать разработчики, а не мы. Все наши решения, так или иначе будут возвращаться к истории сделок. У меня такой критичности по микросекундам нет, но реально
раздражает написание разной сложности велосипедов для того, чтобы узнать, что сделка прошла/не прошла, сработали уровни или кто-то подправил позицию из терминала.
Хотя казалось бы простая вещь - событие на сделку по позиции - и все стало бы намного проще.
Но это должны реализовать разработчики, а не мы.
Разработчики должны только дать инструменты. MQL это по сути низкоуровневый язык программирования (как впрочем и С++). На нем Вы рассуждаете не в терминах задачи, а в терминах вычислений. А все высокоуровневые решения сами делаете. Может не хватать инструментов, но не готовых решений
А в чем пауза\задержка? В копировании 3х структур?
В обработке очереди разноплановых событий.
А как Вам в такой ситуации поможет?
Оно что здесь будет последним, что там
Буду знать о закрытии по тейку.
Нет никакой очереди. Новое событие будет обрабатываться после текущего, а все произошедшие в этот период события будут проигнорированы.
Некомпетентны.
В обработке очереди разноплановых событий.
Буду знать о закрытии по тейку.
Остановимся на том, что я действительно (без кода с HandleNextEvent ) не понимаю элементарных вещей.
Напоследок отмечу, что разница между предлагаемой HandleNextEvent и тем что я написал, в том, что она через рекурсию, а у меня через цикл. В конечном итоге это одно и тоже. Кроме того у меня очередь изначально явно формируется и можно ей управлять... какие то события обрабатываете сразу, какие то откладываете на потом - полная свобода, а через предлагаемую функцию HandleNextEvent - Вы связаны по рукам и ногам
В то же время эта же проверка, зашитая в боевой торговый советник на том же Терминале, Алертит. В чем может быть причина?
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
MT5 и скорость в боевом исполнении
Anton, 2020.05.29 16:21
Скрипт для проверки максимального и среднего времени:
2474.
Стало очень хорошо. Если меняли - Спасибо. Понаблюдаю за показателями в боевом режиме.
PS В боевом режиме, когда совершаются сделки, почти всегда лаги (вывожу только случаи больше 5 миллисекунд).
В остальном, вроде, гораздо лучше, чем 2470.