Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Это терминал 1060, а сервер все еще 1035.
Добрый день, Ренат!
Проектируя "аварийный" режим отслеживания ордера (на случай если не придёт событие OnTradeTransaction),
я обнаружил, что РЫНОЧНЫЙ ордер, появляется в истории БОЛЕЕ, чем через 3 СЕКУНДЫ:
Код советника, выдавший этот лог, прикреплён.
Сначала, время ожидания было 1000 мсек, затем 2000, 3000 и , наконец 4000 мсек
Посылалось 2 команды для каждого периода(открытие позиции - закрытие)
Не слишком ли долго для РЫНОЧНОГО ордера?
P/S Демо-Открытие (билд терминала 1060)
Код еще не запускал, но исходнику видна классическая ошибка неправильной конечной даты в HistorySelect.
Каждый первый программист вызывает эту функцию с неправильной датой, постоянно закусывает конец истории и обнаруживает "долгое попадание сделки в историю".
Вероятно, такова функция, коль "каждый первый" допускает "классическую ошибку".
В том файле есть попытка прочитать историю с некоторой даты до текущего момента. Не подскажите как это сделать корректно, чтоб не "закусывать конец истории"?
Вот ошибка как раз в том, что люди не задумываются, что такое текущий момент и подставляют туда неправильную дату, взятую с неправильного источника.
Достаточно указать в качестве конечной заведомо дальнюю дату, а не устаревший serverTime.
Вот ошибка как раз в том, что люди не задумываются, что такое текущий момент и подставляют туда неправильную дату, взятую с неправильного источника.
Достаточно указать в качестве конечной заведомо дальнюю дату, а не устаревший serverTime.
Может быть тогда можно и справку, с примером в ней поправить?
https://www.mql5.com/ru/docs/trading/historyselect
Renat, работу с функцией OnTradeTransaction() еще не проводили?
Нет, к сожалению, очень занят.
Попробуйте сами на нашем демо-сервере MetaQuotes-Demo, пожалуйста.
Из фразы Рената
Достаточно указать в качестве конечной заведомо дальнюю дату, а не устаревший serverTime.
я понял, что в качестве конечной надо указать завтрашнюю дату (или еще более дальнюю) и будет счастье.
Вот ошибка как раз в том, что люди не задумываются, что такое текущий момент и подставляют туда неправильную дату, взятую с неправильного источника.
Достаточно указать в качестве конечной заведомо дальнюю дату, а не устаревший serverTime.
А к качестве начальной даты, значит и "устаревший" TimeTradeServer() устраивает?
И начальная и конечная дата должна устанавливаться с осознанием погрешностей и с обязательным запасом. То есть минус N сек и плюс N сек как минимум.
TimeTradeServer() - это не рилтайм точное время, а обновляется исключительно по ценовым тикам, приходящим в обзор рынка.
Если у вас в выборке истории вдруг нет данных, значит 99% что ошибка в границах запроса.