Ошибки, баги, вопросы - страница 2179
![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Нет, подгрузка здесь ни при чем.
Если брать не нулевой стартовый бар, а скажем 50 бар, тогда все ОК. Мгновенно.
Причем если беру по 30 бар включительно - зависает. А после нет.
СТОПУДОВЫЙ БАГ!
Попробуйте вот этот:
Попробуйте вот этот:
Да причем тут iBarShift?
Сейчас речь о баге стандартной функции Bars
Да причем тут iBarShift?
Сейчас речь о баге стандартной функции Bars
В той функции тоже Bars() используется. У вас же всё началось как раз с аналога iBarShift()
В той функции тоже Bars() используется. У вас же всё началось как раз с аналога iBarShift()
Да, конечно, юзание аналога iBarShift выявило эту проблему.
Если использовать приведенную Вами функцию iBarShift, этого бага не поймать, т.к. там используется только один ТФ,
А этот баг происходит при использовании разных ТФ в функциях CopyTime и Bars.
Но Bars должен нормально отрабатывать любое время. Но мой пример показывает, что существует частный случай, где iBar зависает на десятки секунд. И подгрузка истории здесь ни причем.
Да, конечно, юзание аналога iBarShift выявило эту проблему.
Если использовать приведенную Вами функцию iBarShift, этого бага не поймать, т.к. там используется только один ТФ,
А этот баг происходит при использовании разных ТФ в функциях CopyTime и Bars.
Но Bars должен нормально отрабатывать любое время. Но мой пример показывает, что существует частный случай, где iBar зависает на десятки секунд. И подгрузка истории здесь ни причем.
Скорее всего это и связано с подгрузкой истории
Да, конечно, юзание аналога iBarShift выявило эту проблему.
Если использовать приведенную Вами функцию iBarShift, этого бага не поймать, т.к. там используется только один ТФ,
А этот баг происходит при использовании разных ТФ в функциях CopyTime и Bars.
Но Bars должен нормально отрабатывать любое время. Но мой пример показывает, что существует частный случай, где iBar зависает на десятки секунд. И подгрузка истории здесь ни причем.
Думаю, что идет попытка цикличной синхронизации в ситуации отсутствия баров в запрошенном диапазоне - Bars во всю старается "нормально отрабатывать" и потом сдается по таймауту или кол-ву попыток синхронизации
Надо самому делать проверки значений , чтобы не вызывать Bars для такого случая.
Скорее всего это и связано с подгрузкой истории
Не согласен. Она бы повторно бы тогда не закачивалась снова 22 секунды. Тем более у меня вся история по всем TФ загружена специальным индикатором.
Если бы это была подгрузка, тогда как объяснить, что первым 31 барам нужна подгрузка, а последующим не нужна.
Если бы это была подгрузка, тогда как объяснить, что первым 31 барам нужна подгрузка, а последующим не нужна.
Из документации: При запросе количества баров в заданном диапазоне дат учитываются только те бары, чье время открытия попадает в этот диапазон.
Соответственно прообраз Bars() возвращает ноль, который интерпретируется как отсутствие истории и ::Bars() в случае скрипта как было верно замечено в предыдущем сообщении завершается по таймауту или числу неудачных попыток.
Думаю, что идет попытка цикличной синхронизации в ситуации отсутствия баров в запрошенном диапазоне - Bars во всю старается "нормально отрабатывать" и потом сдается по таймауту или кол-ву попыток синхронизации
Надо самому делать проверки значений , чтобы не вызывать Bars для такого случая.
Вполне возможно.
Но вариантов масса.
Bars очень важная функция, без нее сложно обойтись. Точнее можно обойтись, но ценой повышенной траты ресурсов.
Необходимо безупречное ее функционирование.
Из документации: При запросе количества баров в заданном диапазоне дат учитываются только те бары, чье время открытия попадает в этот диапазон .
Соответственно прообраз Bars() возвращает ноль, который интерпретируется как отсутствие истории и скрипт как было верно замечено в предыдущем сообщении завершается по таймауту или числу неудачных попыток.
Понятно, что ноль.
И что - это нормально 22 секунды на решение что ноль баров в заданном временном промежутке?
Явный же алгоритмический баг внутренней реализации Bars.
Пожалуй надо оформить заявку в сервисдеск по этому вопросу, а то впереди выходные и эта тема может просто затеряться до понедельника.