Новая версия платформы MetaTrader 5 build 2940: Перенос витрин MQL5-сервисов в рабочую область и обновление дизайна - страница 14
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
2957 есть уже
Спасибо. К сожалению, в b2957 проблема с дебагером не решена.
Уважаемые разработчики, сделайте доступ к стакану из сервиса.
Нужны функции MarketBookAdd(), MarketBookRelease(), MarketBookGet().
Алготрейдинг из сервиса разрешен, а доступа к стакану нет.
Уважаемые разработчики,
будет ли реализован полноценный мост к криптобиржам? Хотя бы к Binance. Не хотелось бы пользоваться костылями.
Хотелось бы понять принципиально - да, это будет или нет - мы этим заниматься не будем.
Уважаемые разработчики,
будет ли реализован полноценный мост к криптобиржам? Хотя бы к Binance. Не хотелось бы пользоваться костылями.
Хотелось бы понять принципиально - да, это будет или нет - мы этим заниматься не будем.
Так платформу должен кто то купить, брокер, который обеспечит доступ клиентов через терминал и будет платить MQ, а крипто биржи работают без посредников, или уже нет?
При оптимизации получаю ошибку:
"
2021.06.11 05:24:31.158 Core 3 pass 328 tested with error "no memory in OnTick function (cannot get 1920 Kb, used 4287 Mb)" in 0:00:03.326
"
Одиночный проход работает корректно.
Памяти занято в районе 30% от 24 гигабайт.
При оптимизации получаю ошибку:
"
2021.06.11 05:24:31.158 Core 3 pass 328 tested with error "no memory in OnTick function (cannot get 1920 Kb, used 4287 Mb)" in 0:00:03.326
"
Одиночный проход работает корректно.
Памяти занято в районе 30% от 24 гигабайт.
Серьезная ошибка в работе с историей торгов.
Во время торговли в историческую таблицу ордеров попадают все новые и новые записи об ордерах. Логично, что только что исполненный/удаленный ордер должен дозаписываться в конец этой таблицы.
Т.е. если видите, что HistoryOrdersTotal увеличился на единицу, то последний элемент в HistorySelect-таблице ордеров и является только что исполненным/удаленным ордером. Иначе говоря, эти ордера в таблице отсортированы по своему Done-времени. Со сделками именно так обстоят дела. Однако, с ордерами - совсем нет.
Скрипт выше это показывает. Он просто подсчитывает, сколько ситуаций, когда в таблице ордер имеет Done-время больше, чем ордер, который стоит после него.
Результат запуска такой.
В таблице 38 тысяч записей именно такие из 114 тысяч - треть.
Прошу разработчиков прокомментировать данное обстоятельство. Надеюсь, это ошибка подготовки исторических кешей для советников.
Правильно ли понимаю, что (за исключением правок задним числом) только что исполненный/удаленный ордер во время работы советника попадает в конец HistorySelect-таблицы - имеет самый большой индекс для HistoryOrderGetTicket?
Серьезная ошибка в работе с историей торгов.
Во время торговли в историческую таблицу ордеров попадают все новые и новые записи об ордерах. Логично, что только что исполненный/удаленный ордер должен дозаписываться в конец этой таблицы.
Т.е. если видите, что HistoryOrdersTotal увеличился на единицу, то последний элемент в HistorySelect-таблице ордеров и является только что исполненным/удаленным ордером. Иначе говоря, эти ордера в таблице отсортированы по своему Done-времени. Со сделками именно так обстоят дела. Однако, с ордерами - совсем нет.
Скрипт выше это показывает. Он просто подсчитывает, сколько ситуаций, когда в таблице ордер имеет Done-время больше, чем ордер, который стоит после него.
Результат запуска такой.
В таблице 38 тысяч записей именно такие из 114 тысяч - треть.
Прошу разработчиков прокомментировать данное обстоятельство. Надеюсь, это ошибка подготовки исторических кешей для советников.
Правильно ли понимаю, что (за исключением правок задним числом) только что исполненный/удаленный ордер во время работы советника попадает в конец HistorySelect-таблицы - имеет самый большой индекс для HistoryOrderGetTicket?
Всегда так было. Там скорее всего привязка к времени установки. Точнее уже не помню. Тоже думал, что последний сработавший должен быть последним в списке, но оказалось, что это далеко не так. Пришлось искать ордера, вместо получения последнего.
Всегда так было. Там скорее всего привязка к времени установки. Точнее уже не помню. Тоже думал, что последний сработавший должен быть последним в списке, но оказалось, что это далеко не так. Пришлось искать ордера, вместо получения последнего.
Заменил в скрипте ORDER_TIME_DONE_MSC на ORDER_TIME_SETUP_MSC.
Да, ордера отсортированы по времени установки. Это принципиальная ошибка! Очень прошу разработчиков высказаться по этому поводу. Жутко тормозной и нелогичный код получается, если нужно что-то отслеживать, синхронизировать и т.д. Такое ощущение, что это просто ошибка опечатки в коде: вместо Done написали Setup.
ЗЫ Похоже, время никак не анализировали. Просто по ORDER_TICKET сортировка. Для сделок это логично. Для ордеров - абсолютно нет!Заменил в скрипте ORDER_TIME_DONE_MSC на ORDER_TIME_SETUP_MSC.
Да, ордера отсортированы по времени установки. Это принципиальная ошибка! Очень прошу разработчиков высказаться по этому поводу. Жутко тормозной и нелогичный код получается, если нужно что-то отслеживать, синхронизировать и т.д. Такое ощущение, что это просто ошибка опечатки в коде: вместо Done написали Setup.
ЗЫ Похоже, время никак не анализировали. Просто по ORDER_TICKET сортировка. Для сделок это логично. Для ордеров - абсолютно нет!Скорее всего, логика там такая из-за нескольких разных самостоятельных списков (ордера, сделки, позиции). Каждый список сортирован по (не помню точно) тикету (или времени? проверять нужно. Проверял, но уже забыл). Вот и вся логика. Три самостоятельных списка. Из позиции можно достать сделки, из сделок - ордера. Но каждый список самостоятелен и не зависит от соседних списков.
Почему так? Наверное это логично - вести три самостоятельных списка каждый со своей независимой сортировкой.