Еще раз, я не исправляю данные всего буфера, лишь только короткий участок, если вы обратите внимание на скрин, то складывается впечатление, что произошло копирование участка буфера со сдвигом, такие манипуляции я делаю в других индикаторах, но в этом ничего подобного.
Наверное ни для кого не будет секретом, что порой котировки транслируемые в реальном времени, позже в истории могут быть "слегка" скорректированы, предполагаю, что именно это и является причиной такого ералаша в буфером индикатора.
Наверное ни для кого не будет секретом, что порой котировки транслируемые в реальном времени, позже в истории могут быть "слегка" скорректированы, предполагаю, что именно это и является причиной такого ералаша в буфером индикатора.
Котировки изменены настолько, что ваш индикатор с ног на голову скрутило?
Полный код = решение проблемы. Поверьте, тут все СТОЛЬКО разных кодов видели, что ваш код ни для кого не станет откровением великого Грааля.
что-то происходит и в результате данные индикатора не чтобы сдвигаются а меняются местами. Что является причиной и как с этим бороться?
Если это то, о чем я думаю,
то когда число баров на графике превысит настройку терминала "Макс. баров в окне", МТ частично обрезает "лишние", по его мнению, бары справа (бары индикаторных буферов, но не цен).
В результате индикатор, накапливающий данные в реальном времени (например индикатор спреда) безвозвратно теряет часть накопленных данных.
Я детектирую это так, что
Bars
на очередном тике становится меньше чем на предыдущем, а не больше.
Данные индикаторных буферов, которые при этом будут потеряны, на каждом тике сохраняю в свой массив, а после потери восстанавливаю.
Artyom Trishkin: Полный перерасчет - когда rates_total - prev_calculated > 1
В тестере mt4 замечена ситуация, при тестировании на полной скорости, в тестируемый индикатор вызовы поступают не подряд, т.е. на следующем вызове rates_total - prev_calculated может быть равно 4, 10, 157 и т.д. в ТиП я об этом писал. Так что "rates_total - prev_calculated > 1" никак не аргумент для полного пересчета индикатора.
Наверное ни для кого не будет секретом, что порой котировки транслируемые в реальном времени, позже в истории могут быть "слегка" скорректированы, предполагаю, что именно это и является причиной такого ералаша в буфером индикатора.
скорректированные котировки это
prev_calculated == 0и пересчет всего индикатора.
Непробиваемый человек :)
Мне надоело, вышел из дискуссии.
скорректированные котировки это
и пересчет всего индикатора.
т.е. при такой ситуации у меня ломается буфер?
Наверное ни для кого не будет секретом, что порой котировки транслируемые в реальном времени, позже в истории могут быть "слегка" скорректированы, предполагаю, что именно это и является причиной такого ералаша в буфером индикатора.
Непробиваемый человек :)
Мне надоело, вышел из дискуссии.
Спасибо!
т.е. при такой ситуации у меня ломается буфер?
в этой ситуации надо пересчитать все данные индикатора заново, а не их часть.
в этой ситуации надо пересчитать все данные индикатора заново, а не их часть.
что-то происходит и в результате данные индикатора не чтобы сдвигаются а меняются местами. Что является причиной и как с этим бороться?
Если это то, о чем я думаю,
то когда число баров на графике превысит настройку терминала "Макс. баров в окне", МТ частично обрезает "лишние", по его мнению, бары справа (бары индикаторных буферов, но не цен).
В результате индикатор, накапливающий данные в реальном времени (например индикатор спреда) безвозвратно теряет часть накопленных данных.
Я детектирую это так, что
Barsна очередном тике становится меньше чем на предыдущем, а не больше.
Данные индикаторных буферов, которые при этом будут потеряны, на каждом тике сохраняю в свой массив, а после потери восстанавливаю.
Полный перерасчет - когда rates_total - prev_calculated > 1
В тестере mt4 замечена ситуация, при тестировании на полной скорости, в тестируемый индикатор вызовы поступают не подряд, т.е. на следующем вызове rates_total - prev_calculated может быть равно 4, 10, 157 и т.д. в ТиП я об этом писал. Так что "rates_total - prev_calculated > 1" никак не аргумент для полного пересчета индикатора.