Добавление функциональности клиентского терминала

Поле Идентификатор уникально для каждого графика, а не окна с графиком. То что Вы в одном окне используете один график не значит что остальные тоже так делают. В связи с чем в таком виде мы не можем зарегистрировать пожелание.
Т.е. требуется соблюдение уникальности для каждого отдельного графика в каждом отдельном окне.
Тем более не понятно зачем из индикатора может потребоваться Идентификатор графика на который этот индикатор накладывается, ведь в индикаторе Вы и так можете получить все данные без Идентификатора.
Просьба пояснить этот момент.




К сожалению вынуждены отказать т.к. для таких целей существует демо контур.

Михаил, позвольте но в тексте автора нет ничего про метки.

Прошу пояснить что есть "демоконтур" или пнуть, куда обратиться за разъяснениями.

Принимается.
Нужны не отдельные данные по каждой свечке, а упорядоченная (проиндексированная по номеру свечки) таблица всех значений всех свечей для дальнейшего обращения к ней. Функция для работы с источником данных - это усложнение кода и, соответственно, увеличение времени обработки данных. Мой код делает все манипуляции в три строки. Вы же предлагаете обработать каждую свечу отдельно в интерпретаторе, затем свести все данные в одну таблицу и уже работать с ней вместо того, чтобы обратиться единожды к оптимизированной и откомпилированной сишной функции. Мне это напоминает удаление гланд через задницу.

Как пример - интерактивная работа с метками. Где в таблице данных метки индекс свечи? Я переместил метку, она привязана ко времени и цене свечи. Я считал эти данные. Мне не нужны раздельные данные по времени, мне нужен только индекс свечи, к которой привязана метка. Укажите мне легкий способ получения такого индекса.Хорошо, воздержусь. Ибо доказывать, что скорость работы откомпилированной сишной функции выше скорости работы интерпретатора занятие неблагодарное.
Уже указал раньше - не нужны данные свечек, нужны индексы свечек к которым привязаны метки. И это не какая-то отдельная задача, а кусок кода комплексной задачи. Работать же с метками, привязанными ко времени неудобно в силу разрастания программного кода если нужно получить данные свечи. Гораздо эффективнее заранее проиндексировать все свечки по времени, получая доступ к индексу свечи по этому времени для получения конкретной свечи и работой с ее данными. Одно обращение по индексу
-получить индекс свечи по смещению в таблице
вместо следующей последовательности действий:
-сравнить время и дату каждой свечи со временем и датой , полученными из данных метки В ЦИКЛЕ
-получить индекс свечи если совпало
Уверен, что вопрос эффективности данных действий очевиден.
А учитывая, что:
- индикатор работает в потоке терминала
- разработчики всеми правдами и неправдами открещиваются от того, чтобы дать программный доступ к таким элементарным объектам как прямая, луч, канал, полигон и т.д. и предлагают все это заменить тормозной работой с метками,
становится очевидно, что чаяния простых пользователей для разработчиков и компании не на первом месте, хотя в других системах торговли уже давно такие сервисы предоставляются. И потому пользователи часто срываются, как я ранее, хотя, конечно, и не стоило этого делать. Но, полазив по форуму и найдя обещания о внесении изменений "вот-вот, скоро в ближайшей версии", начинаешь нервно про себя материться и плеваться.

Разница существенная, поскольку для получения первоначальной t из getCandlesByIndex используется сишная откомпилированная функция, а для получения всех значений первоначальной Т(к) мне придется использовать цикл интепретатора, что в разы медленнее, а учитывая, что при запуске пересчет ведется аж два раза, картина еще печальнее. Да, переиндексировать мне придется обе таблицы и это займет примерно одинаковое время. Но это второе действие.