CreateDataSource

Есть вопросы по внутренней реализации DataSource.

1) В одном скрипте создаются несколько объектов DataSource по одному инструменту на одном таймфрейме. Внутри QUIK это будут независимые объекты, каждый из которых хранит свои данные, или объекты, имеющие ссылку на общий массив свечных данных?

2) В разных скриптах создаются объекты DataSource. Вопрос тот же.

Спрашиваю потому, что по моим наблюдениям при переходе от использования данных с графиков на использование данных из DataSource выросло использование памяти терминалом QUIK и были прецеденты, когда вылетало окно о нехватке памяти. Хочется стабильности и приходится понимать, при какой реализации потребуется меньше памяти.

Нет ли в QUIK ситуации, когда сборщик мусора не может избавиться от каких-то старых данных DataSource из-за того, что не все ссылки сброшены в nil?

Сам спросил, сам провёл эксперимент, создав 10 000 экземпляров DataSource, имеющих по 3000 свечей, в рамках одного скрипта. Использованная память практически не изменилась, так что у всех этих объектов один массив свечных данных.

А у меня попутно вопрос к разработчикам - чем функция CreateDataSourceEX отличается от CreateDataSource ?
И почему CreateDataSourceEX не описана в документации?

Здравствуйте,
Начнем с того что данный скрипт не "образцовый".
Да, его написал лично я. Да, я сотрудник компании.
Но данный скрипт это лишь пример, который был написан с одной и только одной целью - помочь Вам, как пользователям, понять расчет греков, не более.
И этот скрипт вполне замечательно справляется конкретно с этим.
Я вполне допускаю, что этот скрипт не идеален и не скрываю этого, но он работает и, выполняет именно те фундаментальные функции, которые на него возложены.
Если есть адекватные претензии к логике решения тех или иных задач в скрипте, я с радостью приму их и внесу соответствующие изменения.
Однако, следует заметить что данный код нигде в виде ссылки на сайте не публикуется, а значит, решение будет опубликовано только при очередном запросе на форуме.

А теперь к делу:

А зачем закрывать? Мы потом с этими данными работаем.
Списка нет, так как для разных бирж или рынков, он может быть разный. Есть секретный способ, если при выводе по DDE с формальными заголовками, параметр написан БОЛЬШИМИ буквами, значит он статичный и его заказывать нет нужды. Публиковать в документации эту фишку мы не будем, по своим внутренним причинам.
Тиковый поток - это есть то что мы запрашиваем в ТТП или в ТВС, а интервальный - это агрегированная информация в виде графика.
Если проще, заказывая тиковый поток по ТТП мы получаем саму таблицу ТТП. Если по ТВС, то мы получаем саму таблицу ТВС и можем с ними работать минуя функции работы с графиками. Но если мы заказываем интервал, то мы НЕ получаем ТТП или ТВС, а получаем только график, с которым данный скрипт не работает. И да, мы эту фишку тоже не будем публиковать, по своим внутренним причинам.

Здравствуйте, Можете обосновать или привести пример?
В том скрипте, о котором идет речь, CreateDataSource используется именно для заказа данных.
То есть, для случая когда параметр нигде не заказан, но его нужно получить через getParamEx.

Вы указываете на частный случай, о статусе которого я к сожалению сейчас не готов ответить.
Однако в общем случае, решение доступа к данным в виде заказа через CreateDataSource  должно работать.

Что есть частный случай и что есть общий случай в данной ситуации?

Конкретно в моем примере расчета греков, нет не нужно.
В общем случае, нет представления о ситуации когда это действительно требуется.

У вас работает?
Если вы получаете данные через getParamEx, то заказывать их через CreateDataSource нет смысла, поскольку заказываемые параметры должны быть по-любому в списках принимаемых параметров, независимо от вызова этой функции CreateDataSource.


Не совсем понял ваш комментарий.
Общий случай - это когда заданы все параметры функции CreateDataSource(STRING class_code, STRING sec_code, NUMBER interval, [, STRING param])
Так вот в общем случае "решение доступа к данным в виде заказа через CreateDataSource" не работает.
Оно работает в частном случае, когда не задан последний параметр param, да и то с оговорками.

Это я так, не спора ради, даю информацию Антонио и, видимо вам.

Это работает только если включена настройка "Исходя из настроек открытых пользователем таблиц"
В общем-то да.

Оказывается, связаны.
Если включена настройка "Исходя из настроек открытых пользователем таблиц", то CreateDataSource автоматически добавляет бумагу/параметр в список получаемых параметров.

Таким образом, с помощью getParamEx можно будет получить значения параметров. (Выше я был не прав: CreateDataSource всё же не совсем бесполезна в этой ситуации).

Правда, ds:Close() бумагу уже не из списка не удаляет.

почему я думаю, что CreateDatasource - автономна, т.е. имеет свой LUA-поток? Потому что она служит для прямого получения данных с сервера QUIK и имеет свои коллбеки, которые не связаны со стандартными QLUA-коллбеками, выполняющимися в основном потоке квика для всех скриптов.

Да Close() не удаляет параметр из списков. Такова текущая реализация.
Ранее мы уже регистрировали от другого пользователя пожелание по данной теме.
Можем зарегистрировать еще одно от Вас.

Давайте зарегистрируем.
А то в текущем виде смысла нету в :Close(). Это с таким же успехом можно просто удалить сам объект ds = nil.

По какому принципу отсылаются данные клиенту из образовавшейся очереди? Клиент передаёт серверу, что предыдущие данные им успешно получены? Или как?

Для справки:
Реализовал открытие источников без графиков для индикаторов.
-------------------
алгоритм следующий:
1) сделал библиотеку для запуска  функций любого скрипта из других скриптов
2) Написал скрипт, который отвечает за открытие источников и находится в спящем потоке.
3) Если индикатору или скрипту нужны данные по истории,
то он обращается за данными к спящему скрипту,
который возвращает индикатору требуемые данные.
--------------------

Список ошибок к исправлению был утерян?

Ищу помощь в примере кода на luabind (или голый С) с CreateDataSource и установкой обработчика. Готов оплатить результат.