CreateDataSource

Вам бы модератора на форум.    Злобного.  

А что касается моих сообщений #40 и #42. Ответите?

Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.

Данные будут копиться в очереди.
То есть поток данных как бы поставится на паузу. После окончания работы колбека, пропущенные данные сразу заедут.
Если колбек никогда не завершится, то терминал зависнет и сервер через некоторое время разорвет соединение.

Имеется ввиду, где эти данные будут обработаны?
1) нигде
2) в колбеке
3) в цикле for i = 1, ds:Size() do GetPrice(i) end
4) другое

Где физически находится эта очередь? На сервере? И данные ждут, когда откроется "портал", чтобы "спуститься" к клиенту? Пока работает колбек клиент не доступен для сервера?

Вы можете однозначно ответить все ли данные (1), (2) и (3) будут обработаны в колбеке GetPrice, заданном в SetUpdateCallback?
Что-нибудь изменится, если колбек задать после обработки таблицы в цикле?

Не знаю, что вы подразумеваете под словом "текущие", но основываясь на том, что очередь находится на сервере (блин, ну почему нельзя было сразу об этом сказать?!), я делаю вывод, что данные (1), (2) и (3) будут обработаны функцией-колбеком GetPrice()

По-моему мнение, есть непонимание общих принципов взаимодействия сервера и клиента и колбеков в терминале.
--------------------------------------------
Фактически мы имеем две очереди, а вернее сказать - три:
---------------------------------
1)  очередь заявок брокеров на сервере биржи
2)  очередь поручений клиентов на сервере брокера
3) очередь  колбеков скриптов VMLUA в терминале QUIK на компе клиента,
так как все колбеки в одном потоке терминала.
--------------------------------
Надеюсь, что объяснил понятно.

Потому что вы смотрите регулярный таймфрейм.  Переключитесь на тики.

А теперь переключитесь с демо спота  на демо фортс или на боевые торги.

up

Добрый день,

Ошибка будет исправлена в одной из следующих версий программы.

Скорей всего, проблема в том, что функция SetUpdateCallback возможно работает в другом lua thread и корректный обмен между двумя lua-потоками так и не сделан.

Добрый день.

Речь идет о том, что DS:Close выдает некорректные результаты.

День добрый.

Зашёл в эту тему, чтобы понять как работает CreateDataSource, т.к. ds:Size() мне ноль всегда возвращал. Спасибо добрым людям, что напомнили про callback (В итоге сделал callback-функцию которая просто выставляет флажок, что данные загружены и всё стало отлично).

Но попутно возникло пожелание. Дело в том, что Quik по умолчанию загружает с сервера ~3000 свечек. Но мне, например, нужны данные всего за неделю (это в пределах 100-200 свечек получается), но зато по многим бумагам (например весь класс TQBR, т.е. около 300 штук). Если бы была возможность указать сколько последних свечек загрузить, то это снизило бы размер передаваемых данных раз в десять (полагаю съэкономилось бы несколько десятков мегабайт)
Поэтому прошу рассмотреть возможность добавить к функции CreateDataSource ещё один параметр, который бы определял сколько свечек истории надо загрузить. (При этом вполне допускаю, что кому-то будет даже удобно ставить его равным 0, чтобы экономить и получать данные лишь с текущего момента).

Но всё-таки возник вопрос - какой метод официально рекомендуется, чтобы узнать, что CreateDataSource загрузила все данные, которые были актуальны на момент её вызова?
Поясню на примере, что именно я имею ввиду. Код такой:
Так вот, если sec равно, например "AFLT", то скрипт отрабатывает, завершается и на выходе я имею в output.txt строчку "name: Аэрофлот size: 3013", что абсолютно понятно, правильно.
А вот если я ставлю sec равной "ERCO", то скрипт подвисает и, после его прерывания, в output.txt я получаю лишь "name: ЭРКО ао".

Очевидно, что не срабатывает callback для бумаги ERCO. Судя по тому, что я вижу в терминале - по бумаге ERCO торгов давно (или вообще) не было. Очевидно с сервера приходит пустой массив данных. Но ведь он приходит (файл TQBR_ERCO_15.dat размером 41 байт в каталоге archives присутствует), поэтому вопросы:
1) почему в данном случае не срабатывает callback? (предполагаю, что потому, что нет данных, но тогда возникает куда более важный вопрос №2)
2) как понять, что уже пора перестать ждать данные, принять size=0 и пойти по жизни дальше? (как отличить ситуацию продолжения ожидания данных с сервера от ситуации отсутствия данных?)

Прошу понять, что прочитать весь форум довольно затруднительно, а поиском не всегда находится нужное.
Поэтому ещё вопрос - а планируется ли добавление срабатывания callback'а в такой ситуации? Ведь это решило бы проблему.

Хорошо, я допускаю, что интерфейс клиент-сервер не позволяет сделать в этом месте элегантное решение.
Но ситуация на мой взгляд требует улучшения, поэтому следующие возможные предложения:
1) Можно ли добавить функцию
NUMBER  getDataCount(STRING class_code, STRING sec_code, NUMBER interval, [, STRING param])
которая бы сообщала сколько на данный момент есть данных на сервере для данного инструмента? (подозреваю, что отличие будет только COUNT в SQL запросе, но повысит нагрузку на сервер...)
2) Или же добавить функции getSecurityInfo() ещё один возвращаемый параметр. По хорошему конечно дату-время последней известной серверу сделки. Но думаю это не впишется в архитектуру клиент-серверных вызовов. Поэтому может не очень элегантно, но зато просто и надёжно - true-false параметр указывающий были ли сделки до начала сегодняшней торговой сессии. Выглядит может и не очень красиво, но я уверен, что это решит 99% случаев возникновения моего вопроса.

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

а как отличить что это не одно и тоже?
На графике есть

А почему бы не сделать дополнительную функцию, при вызове которой будет возвращаться количество свечей, которое было на сервере по заданному инструменту на момент вызова этой функции?
Она отрабатывала бы намного быстрей, чем CreateDataSource, т.к. не требовалось бы передавать весь массив свечей на терминал.
Вызвав ее, мы смогли бы узнать, какое минимальное количество свечей должна вернуть нам CreateDataSource.
И, самое главное, эта функция всегда возвращала бы нам какое-то определенное значение, даже если свечей по данному инструменту на сервере нет.
Если при вызове этой новой функции мы получим 0, то будем знать, что нет смысла ждать поступления каких-либо данных. Таким образом, проблема бесконечного ожидания была бы устранена на 100%.
По-моему, нет ничего невозможного в реализации такой функции.
Прошу зарегистрировать соответствующее пожелание на доработку.

Дмитрий, спасибо за поддержку, именно это, я и имел ввиду, когда предлагал функцию getDataCount в сообщении #84

По-моему, Вы не вникли в смысл темы, которая обсуждалась выше.
Речь идет о получении истории свечей при первоначальном вызове CreateDataSource (которая обычно достигает 3000 свечей за прошлые дни, плюс сегодняшние свечи). Этот процесс занимает неопределенное время (особенно при одновременном открытии источников данных по нескольким инструментам), а скрипт должен ждать окончания загрузки данных.
Прежде всего нам нужно знать, есть ли вообще такая история на сервере.
Если на момент вызова CreateDataSource на сервере нет ни одной свечи, то мы можем ждать бесконечно долго пока функция Size() вернет значение, большее 0, или придет коллбэк.
Смысл запрашивать количество свечей на сервере есть, и он состоит в том, чтобы избежать подобных ситуаций.

Пардон,
действительно,
нет надобности обновлять историю которая уже есть в терминале.
Было бы хорошо,
если бы история в терминале в начале сессии  не обновлялась,
а добавлялась.

То есть если график не открыт, то CreateDataSource вообще не выдаст нам свечи, сохраненные в кэше?