Исправление котировок задним числом. Как быть подготовленным к этому?

Новый комментарий
 

Источник головной боли: индикатор, который перерассчитывается только на последнем экстремуме. Мы с автором этого индикатора пытались понять, почему иногда он начинает сбоить:

Скорее всего это вызвано исправлением котировок задним числом, а логика индикатора естественно к этому не готова. Вот тот же участок, но через пару минут.

Не вооружённым глазом видно, что котировки уже совсем другие:

Кто встречал подобное и как обходил? Встроенных средств я как понимаю для этого нет?

 

никак

где-то на форуме Альпари видел инфу о том как работает терминал с сервером, вроде бы на своем ТФ терминал строит бары по пришедшим тикам, НО через некоторое время терминал автоматически синхронизирует историю на открытых графиках, чтобы синхронизировать принудительно - правой мышью - обновить,вроде так изначально спроектировано

ЗЫ: пишу по памяти - первоисточник чет ненагуглю никак

 
IgorM:

никак

где-то на форуме Альпари видел инфу о том как работает терминал с сервером, вроде бы на своем ТФ терминал строит бары по пришедшим тикам, НО через некоторое время терминал автоматически синхронизирует историю на открытых графиках, чтобы синхронизировать принудительно - правой мышью - обновить,вроде так изначально спроектировано

ЗЫ: пишу по памяти - первоисточник чет ненагуглю никак


Ну я так и думаю.... Весь вопрос в алгоритме - через какое время и сколько баров синхронизируется....
 
AlexSTAL:

Ну я так и думаю.... Весь вопрос в алгоритме - через какое время и сколько баров синхронизируется....

сколько? сколько было новых баров с последнего момента синхронизации столько и будет вновь синхронизированно, сейчас поищу, в формате файла истории в заголовке файла есть время последней синхронизации, наверно от этого времени и будет все загружено
 

вот часть кода стандартного period_converter:

//---- write history file header
   c_copyright="(C)opyright 2003, MetaQuotes Software Corp.";
   FileWriteInteger(ExtHandle, version, LONG_VALUE);
   FileWriteString(ExtHandle, c_copyright, 64);
   FileWriteString(ExtHandle, c_symbol, 12);
   FileWriteInteger(ExtHandle, i_period, LONG_VALUE);
   FileWriteInteger(ExtHandle, i_digits, LONG_VALUE);
   FileWriteInteger(ExtHandle, 0, LONG_VALUE);       //timesign
   FileWriteInteger(ExtHandle, 0, LONG_VALUE);       //last_sync
   FileWriteArray(ExtHandle, i_unused, 0, 13);
//---- write history file

по сабжу - или самому попытаться файл истории править время синхронизации, чтобы графики не перерисовывались или параллельно в коде индикатора вести некий лог OHLC для не посчитанных баров

ЗЫ: вот неплохой пример для подкачки истории на всю возможную глубину, с помощью правки времени синхронизации истории: https://www.mql5.com/ru/code/9888

 
IgorM:

вот часть кода стандартного period_converter:

по сабжу - или самому попытаться файл истории править время синхронизации, чтобы графики не перерисовывались или параллельно в коде индикатора вести некий лог OHLC для не посчитанных баров

Благодарю! Будем думать
 

и если не ошибаюсь, то момент автоподкачки/синхронизации ТФ происходит при выполнении такого нелогичного кода:

int counted;

....

int start(){
....
int bar = Bars;
if (bar != counted ) {
   counted= bar;

}
 
IgorM:

и если не ошибаюсь, то момент автоподкачки/синхронизации ТФ происходит при выполнении такого нелогичного кода:


Это просто обработка нового бара как мне кажется....

или докачка истории... но не синхронизации....

 

значит по закрытию нового бара сверять ранее запомненные OHLC с текущими на ТФ, и в случае несовпадения принимать решение, ф-ция ArrayCopySeries() для индикатора может скопировать в индексные массивы данные, которые потом сверять

ЗЫ: я наблюдал такое "чудо" онлайн - прям на глазах история на экране перерисовывалась, для ордеров в рынке это уже не страшно, а вот для принятия нового решения на основе текущей истории - увы

 
IgorM:

значит по закрытию нового бара сверять ранее запомненные OHLC с текущими на ТФ, и в случае несовпадения принимать решение, ф-ция ArrayCopySeries() для индикатора может скопировать в индексные массивы данные, которые потом сверять

1) ArrayCopyRates- это функция для отсылки данных в Dll
2) Копирования при вызове ArrayCopyRates() не происходит- происходит перенаправление обращений
на внутренний массив МТ (который суть есть копия данных, предназначенная для текущего индикатора)-
соответственно, что с чем будет сравниваться?

Если не прав- поправьте.
 
jartmailru:
1) ArrayCopyRates- это функция для отсылки данных в Dll
2) Копирования при вызове ArrayCopyRates() не происходит- происходит перенаправление обращений

1. в учебнике в качестве пояснения написанно: "Замечания: обычно массив используется, чтобы передать данные в DLL функцию.", а выше описание ф-ции:"Копирует в двухмерный массив, вида RateInfo[][6], данные баров текущего графика и возвращает количество скопированных баров"

2.учебник:"Реального распределения памяти под массив данных и копирования не происходит. При обращении к такому массиву производится перенаправление доступа."

ЗЫ: я рекомендовал другую ф-цию - ArrayCopySeries(), она по разному работает для индикаторных буферов и просто массивов

12
Новый комментарий
Причина обращения: