Как доработать OnCalculate чтоб было удобно реализовывать Каги, Ренко и прочие индикаторы отвязанные от времени?

[Mykola Demko]

Предлагаю к обсуждению тему топика.

По результатам обсуждения (если будет достойный вариант) сформируем заявку с пожеланием в Сервисдеск.

Так же можно обсуждать "а надали такая перегрузка вообще".

---

Моё предложение такое:

int OnCalculate(const int rates_total,
                int& rates_total_ind,
                const int prev_calculated,
                const datetime &time[],
                const double &open[],
                const double &high[],
                const double &low[],
                const double &close[],
                const long &tick_volume[],
                const long &volume[],
                const int &spread[])

Добавить в перегрузку функции дополнительную переменную int& rates_total_ind, от которой зависит распределение памяти индикаторных массивов, массивы должны отображаться от rates_total-1 бара назад. Соответственно пока rates_total_ind не изменилось (а изменяет его пользователь) индикаторные массивы будут привязаны к бару rates_total-1.

const int prev_calculated же будет (как и раньше) зависеть от возвращаемого значения в return.

ЗЫ направление нумерации массивов можно оставить как есть чтоб не нарушать сложившуюся традицию.

ЗЗЫ Для тех кто не в теме проблемы, сейчас для индикаторов отвязанных от времени приходится бороться со встроенным механизмом сдвига массива при приходе нового бара перемещая массив на прежнее место (причём двигать приходится весь многотысячный массив), так же при наступлении события нового бара в индикаторе приходится делать сдвиг назад.

[Mykola Demko]

Кстати потребуется ещё перегрузить функцию Bars поскольку количество бар индикатора может отличаться от символьных баров

int  Bars( int handle        // хендл индикатора
         );

[Stanislav Korotky]

По идее, нужно перегружать функцию формирования нового бара в самом ядре, и из нее вызывать какое-то новое событие, типа OnBarCreate, из которой MQL5 передает признак, когда появляется следующий бар.

[Mykola Demko]

marketeer:
По идее, нужно перегружать функцию формирования нового бара в самом ядре, и из нее вызывать какое-то новое событие, типа OnBarCreate, из которой MQL5 передает признак, когда появляется следующий бар.

Идея конечно фундаментальная, если будет сделано то отсюда не далеко и до пользовательского чарта.

Но уж больно много затрагивает, а посему (имхо) сложно будет продавить в умы разработчиков.

Но в месте с тем имеет место быть, может кто предложит простую реализацию этого концепта.

Наберём идей, а там будет видно.

[Roman Zamozhnyy]

По моему, не получится. Ренко, Каги, ХО - принципиально иной тип графика, они, как вы верно сказали, отвязаны от времени, нет в них баров, цен открытия, закрытия, максимумов и минимумов, а только тиковая история Бид или Аск и, если брокер даёт - объём. Для таких графиков надо писать отдельную функцию, типа:

int OnOtherGraph(const double &bid[]);

[Konstantin Gruzdev]

Да, нужно сделать, чтобы был режим для чарта, когда пользователь мог сам формировать событие "новый бар" для него. OnCalculate() трогать не нужно. 

Как я вижу, то схема должна быть приблизительно такая:

1. С помощью, к примеру, #property устанавливается свойство custom_char. Это означает, что штатное событие "новый бар" отключается, штатный график не отрисовывается , но не отключаются тики и есть возможность как обычно отображать индикаторы. Это позволит делать статические чарты, и делать информационные панели, где движение графика не требуется, но благодаря тикам или таймеру возможно обновление данных.
2.  Плюс включить в список событие CHARTEVENT_NEWBAR, которое пользователь может отправлять с помощью стандартной функции EventChartCustom(). Отправка этого события вызывает:

• увеличение счетчика баров
• формирование шкалы времени по проходу события  CHARTEVENT_NEWBAR, шкала будет явно нелинейная
• смещение индикаторных буферов и пересчет индикаторов (штатных и пользовательских)
• смещение всех графических объектов, которые смещаются на стандартном графике
• возможно еще чего-то.