Старатель пишет: Раз уж тут у нас получился "Вечер откровений" касательно работы функции CreateDataSource, то предлагаю вернуться к проблеме (CQ01544135), когда CreateDataSource не заказывает данные параметров с сервера, как изначально планировалось. Предлагаю создать новую функцию, предназначенную непосредственно для заказа параметров бумаг, аналог меню "Связь - Списки...", и не завязывать получение этих параметров на CreateDataSource.
Т.е., если нужно получить только последнее значение параметра (без истории) через getParamEx или колбек OnParam, то заказывать данные с помощью новой функции. Если нужна истории параметров, то CreateDataSource.
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Sergey Gorokhov пишет: Колбеки в QUIK идут в основном потоке терминала, поэтому никаких "тут приходят данные" просто не будет.
Объясните. Вот в OnInit() или любом другом колбеке реализован сложный алгоритм, который занимает длительное время. Пока колбек занят, сервер шлёт клиенту новую порцию данных. Что происходит с этими данными? Клиент их не принимает? И когда освободится сервер отправит эти же данные повторно?
Надо делать так, как надо. А как не надо - делать не надо.
Sergey Gorokhov пишет: Колбеки в QUIK идут в основном потоке терминала, поэтому никаких "тут приходят данные" просто не будет.
Объясните. Вот в OnInit() или любом другом колбеке реализован сложный алгоритм, который занимает длительное время. Пока колбек занят, сервер шлёт клиенту новую порцию данных. Что происходит с этими данными? Клиент их не принимает? И когда освободится сервер отправит эти же данные повторно?
Данные будут копиться в очереди. То есть поток данных как бы поставится на паузу. После окончания работы колбека, пропущенные данные сразу заедут. Если колбек никогда не завершится, то терминал зависнет и сервер через некоторое время разорвет соединение.
Sergey Gorokhov пишет: Данные будут копиться в очереди. То есть поток данных как бы поставится на паузу. После окончания работы колбека, пропущенные данные сразу заедут.
Уже лучше. Т.е., клиент всё-таки их примет? Теперь хотелось бы узнать, если данные придут в таком порядке, как в примере, то куда они попадут после окончания работы OnInit?
Надо делать так, как надо. А как не надо - делать не надо.
Старатель пишет: Имеется ввиду, где эти данные будут обработаны? 1) нигде 2) в колбеке 3) в цикле for i = 1, ds:Size() do GetPrice(i) end 4) другое
Вопрос не понятен. Еще раз повторю, пока работает колбек, новые данные никуда не идут, они копятся в очереди. Когда колбек закончит работу пропущенные данные заедут в том порядке в котором скопились. И последующие события сработают ровно в том же порядке в котором они бы сработали если бы в событии OnInit ничего не было.
В Вашем примере это значит что никаких "нигде" в принципе быть не может. никаких "в колбеке" в принципе быть не может. никаких "в цикле" в принципе быть не может.
Ответ ровно один, пропущенные данные будут обработаны ровно так как если бы они не были пропущенными.
Sergey Gorokhov пишет: пока работает колбек, новые данные никуда не идут, они копятся в очереди.
Где физически находится эта очередь? На сервере? И данные ждут, когда откроется "портал", чтобы "спуститься" к клиенту? Пока работает колбек клиент не доступен для сервера?
Вы можете однозначно ответить все ли данные (1), (2) и (3) будут обработаны в колбеке GetPrice, заданном в SetUpdateCallback? Что-нибудь изменится, если колбек задать после обработки таблицы в цикле?
Код
function OnInit(script_path)
ds = CreateDataSource(ClassCode, SecCode, Interval)
-- тут приходят данные (1)
local function GetPrice(index)
Candles[index] = ds:C(index)
end
-- тут приходят данные (2)
for i = 1, ds:Size() do GetPrice(i) end
-- тут приходят данные (3)
ds:SetUpdateCallback(GetPrice)
end
Надо делать так, как надо. А как не надо - делать не надо.
Старатель пишет: Где физически находится эта очередь? На сервере? И данные ждут, когда откроется "портал", чтобы "спуститься" к клиенту? Пока работает колбек клиент не доступен для сервера?
На сервере
Цитата
Старатель пишет: Вы можете однозначно ответить все ли данные (1), (2) и (3) будут обработаны в колбеке GetPrice, заданном в SetUpdateCallback?
Только текущие.
Цитата
Старатель пишет: Что-нибудь изменится, если колбек задать после обработки таблицы в цикле?
Старатель пишет: Вы можете однозначно ответить все ли данные (1), (2) и (3) будут обработаны в колбеке GetPrice, заданном в SetUpdateCallback?
Только текущие.
Не знаю, что вы подразумеваете под словом "текущие", но основываясь на том, что очередь находится на сервере (блин, ну почему нельзя было сразу об этом сказать?!), я делаю вывод, что данные (1), (2) и (3) будут обработаны функцией-колбеком GetPrice()
Надо делать так, как надо. А как не надо - делать не надо.
Старатель пишет: Вы можете однозначно ответить все ли данные (1), (2) и (3) будут обработаны в колбеке GetPrice, заданном в SetUpdateCallback?
Только текущие.
Не знаю, что вы подразумеваете под словом "текущие", но основываясь на том, что очередь находится на сервере (блин, ну почему нельзя было сразу об этом сказать?!), я делаю вывод, что данные (1), (2) и (3) будут обработаны функцией-колбеком GetPrice()
Под текущие имеется в виду все которые есть на момент события OnInit. Но свежие данные тоже продолжат поступать в колбек GetPrice, если Вы об этом. Прошу прощения за неточность в предыдущем ответе
Старатель пишет: Не знаю, что вы подразумеваете под словом "текущие", но основываясь на том, что очередь находится на сервере (блин, ну почему нельзя было сразу об этом сказать?!), я делаю вывод, что данные (1), (2) и (3) будут обработаны функцией-колбеком GetPrice()
По-моему мнение, есть непонимание общих принципов взаимодействия сервера и клиента и колбеков в терминале. -------------------------------------------- Фактически мы имеем две очереди, а вернее сказать - три: --------------------------------- 1) очередь заявок брокеров на сервере биржи 2) очередь поручений клиентов на сервере брокера 3) очередь колбеков скриптов VMLUA в терминале QUIK на компе клиента, так как все колбеки в одном потоке терминала. -------------------------------- Надеюсь, что объяснил понятно.
Функции O, H, L, C, V, T Функции в качестве параметра принимают индекс свечи и возвращают соответствующее значение. Время свечи возвращается с точностью до миллисекунд в виде таблицы с полями: {year, month, day, week_day, hour, min, sec, ms, count}
Почему параметры sec и ms всегда равны нулю?
Надо делать так, как надо. А как не надо - делать не надо.
Функции O, H, L, C, V, T Функции в качестве параметра принимают индекс свечи и возвращают соответствующее значение. Время свечи возвращается с точностью до миллисекунд в виде таблицы с полями: {year, month, day, week_day, hour, min, sec, ms, count}
Почему параметры sec и ms всегда равны нулю?
Потому что вы смотрите регулярный таймфрейм. Переключитесь на тики.
Старатель пишет: Переключился на тиковый интервал: секунды появились. Но милисекунды не транслируются.
А теперь переключитесь с демо спотана демо фортс или на боевые торги.
Я имел ввиду для параметров из ТТП. На боевом сервере мс не транслируются для параметров.
Ещё такой вопрос.
Код
function main()
tDS = CreateDataSource('QJSIM', 'SBER', INTERVAL_M1)
tDS:SetUpdateCallback(function(nIndex) end)
message('[main] '..tostring((tDS:Close())), 2)
end
Результат: [main] true
Код
local bRun, tDS = true
function OnStop()
bRun = nil
end
function main()
tDS = CreateDataSource('QJSIM', 'SBER', INTERVAL_M1)
tDS:SetUpdateCallback(function(nIndex) end)
while bRun do sleep(200) end
message('[main] '..tostring((tDS:Close())), 2)
end
Результат: [main] nil
Код
local bRun, tDS = true
function OnStop()
message('[OnStop] '..tostring((tDS:Close())), 2)
bRun = nil
end
function main()
tDS = CreateDataSource('QJSIM', 'SBER', INTERVAL_M1)
tDS:SetUpdateCallback(function(nIndex) end)
while bRun do sleep(200) end
end
Результат: [OnStop] nil
Код
local bRun, tDS = true
function OnStop()
message('[OnStop] '..tostring((tDS:Close())), 2)
bRun = nil
end
function main()
tDS = CreateDataSource('QJSIM', 'SBER', INTERVAL_M1)
tDS:SetUpdateCallback(function(nIndex) end)
while bRun do sleep(200) end
message('[main] '..tostring((tDS:Close())), 2)
end
Результат: [OnStop] nil [main] false
Можете объяснить результаты?
Надо делать так, как надо. А как не надо - делать не надо.
Старатель пишет: Переключился на тиковый интервал: секунды появились. Но милисекунды не транслируются.
А теперь переключитесь с демо спотана демо фортс или на боевые торги.
Я имел ввиду для параметров из ТТП. На боевом сервере мс не транслируются для параметров.
Ещё такой вопрос.
Код
function main()
tDS = CreateDataSource('QJSIM', 'SBER', INTERVAL_M1)
tDS:SetUpdateCallback(function(nIndex) end)
message('[main] '..tostring((tDS:Close())), 2)
end
Результат: [main] true
Код
local bRun, tDS = true
function OnStop()
bRun = nil
end
function main()
tDS = CreateDataSource('QJSIM', 'SBER', INTERVAL_M1)
tDS:SetUpdateCallback(function(nIndex) end)
while bRun do sleep(200) end
message('[main] '..tostring((tDS:Close())), 2)
end
Результат: [main] nil
Код
local bRun, tDS = true
function OnStop()
message('[OnStop] '..tostring((tDS:Close())), 2)
bRun = nil
end
function main()
tDS = CreateDataSource('QJSIM', 'SBER', INTERVAL_M1)
tDS:SetUpdateCallback(function(nIndex) end)
while bRun do sleep(200) end
end
Результат: [OnStop] nil
Код
local bRun, tDS = true
function OnStop()
message('[OnStop] '..tostring((tDS:Close())), 2)
bRun = nil
end
function main()
tDS = CreateDataSource('QJSIM', 'SBER', INTERVAL_M1)
tDS:SetUpdateCallback(function(nIndex) end)
while bRun do sleep(200) end
message('[main] '..tostring((tDS:Close())), 2)
end
Результат: [OnStop] nil [main] false
Можете объяснить результаты?
Здравствуйте!
Информация получена, проблема изучается. Постараемся в ближайшее время дать ответ.
Старатель пишет: Переключился на тиковый интервал: секунды появились. Но милисекунды не транслируются.
А теперь переключитесь с демо спотана демо фортс или на боевые торги.
Я имел ввиду для параметров из ТТП. На боевом сервере мс не транслируются для параметров.
Ещё такой вопрос.
Код
function main()
tDS = CreateDataSource('QJSIM', 'SBER', INTERVAL_M1)
tDS:SetUpdateCallback(function(nIndex) end)
message('[main] '..tostring((tDS:Close())), 2)
end
Результат: [main] true
Код
local bRun, tDS = true
function OnStop()
bRun = nil
end
function main()
tDS = CreateDataSource('QJSIM', 'SBER', INTERVAL_M1)
tDS:SetUpdateCallback(function(nIndex) end)
while bRun do sleep(200) end
message('[main] '..tostring((tDS:Close())), 2)
end
Результат: [main] nil
Код
local bRun, tDS = true
function OnStop()
message('[OnStop] '..tostring((tDS:Close())), 2)
bRun = nil
end
function main()
tDS = CreateDataSource('QJSIM', 'SBER', INTERVAL_M1)
tDS:SetUpdateCallback(function(nIndex) end)
while bRun do sleep(200) end
end
Результат: [OnStop] nil
Код
local bRun, tDS = true
function OnStop()
message('[OnStop] '..tostring((tDS:Close())), 2)
bRun = nil
end
function main()
tDS = CreateDataSource('QJSIM', 'SBER', INTERVAL_M1)
tDS:SetUpdateCallback(function(nIndex) end)
while bRun do sleep(200) end
message('[main] '..tostring((tDS:Close())), 2)
end
Результат: [OnStop] nil [main] false
Можете объяснить результаты?
Здравствуйте!
Информация получена, проблема изучается. Постараемся в ближайшее время дать ответ.
Добрый день,
Ошибка будет исправлена в одной из следующих версий программы.
Sergey Gorokhov пишет: Ошибка будет исправлена в одной из следующих версий программы.
Вы только, пожалуйста, для всех нас потом объясните, что это за очередная ошибка, по какой причине возникла и что сделано, чтобы ошибок такого вида впредь не возникало. А то, мы постоянно слышим Ваше - "было исправлено", которое надо понимать так: мол де "ну чота исправили где-то, а что х.. его знает. Но ведь исправили и ладно", А потом выясняется, что надо ждать очередной пакет обновления с новой порцией багов. И в очередной раз задавать "глупые вопросы" непосредственно создателю: "ё-маё, а шо это было на самом деле", ну и в том же духе. ---------------------------------------- В общем, подытожив: то, что Вы исправите - это уже следствие, но нам также и важна причина, чтоб оценить свои риски.
Скорей всего, проблема в том, что функция SetUpdateCallback возможно работает в другом lua thread и корректный обмен между двумя lua-потоками так и не сделан.
Старатель пишет: Раз уж тут у нас получился "Вечер откровений" касательно работы функции CreateDataSource, то предлагаю вернуться к проблеме (CQ01544135), когда CreateDataSource не заказывает данные параметров с сервера, как изначально планировалось. Предлагаю создать новую функцию, предназначенную непосредственно для заказа параметров бумаг, аналог меню "Связь - Списки...", и не завязывать получение этих параметров на CreateDataSource.
Т.е., если нужно получить только последнее значение параметра (без истории) через getParamEx или колбек OnParam, то заказывать данные с помощью новой функции. Если нужна истории параметров, то CreateDataSource.
Добрый день,
Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам, что реализация пожелания признана потенциально целесообразной. Если по результатам дальнейшего анализа, включающего юридические аспекты, анализ на непротиворечивость с общей политикой компании, никаких возражений не возникнет, мы постараемся включить Ваше пожелание в план доработок при выпуске одной из следующих версий нашего ПО.
Зашёл в эту тему, чтобы понять как работает CreateDataSource, т.к. ds:Size() мне ноль всегда возвращал. Спасибо добрым людям, что напомнили про callback (В итоге сделал callback-функцию которая просто выставляет флажок, что данные загружены и всё стало отлично).
Но попутно возникло пожелание. Дело в том, что Quik по умолчанию загружает с сервера ~3000 свечек. Но мне, например, нужны данные всего за неделю (это в пределах 100-200 свечек получается), но зато по многим бумагам (например весь класс TQBR, т.е. около 300 штук). Если бы была возможность указать сколько последних свечек загрузить, то это снизило бы размер передаваемых данных раз в десять (полагаю съэкономилось бы несколько десятков мегабайт) Поэтому прошу рассмотреть возможность добавить к функции CreateDataSource ещё один параметр, который бы определял сколько свечек истории надо загрузить. (При этом вполне допускаю, что кому-то будет даже удобно ставить его равным 0, чтобы экономить и получать данные лишь с текущего момента).
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Но всё-таки возник вопрос - какой метод официально рекомендуется, чтобы узнать, что CreateDataSource загрузила все данные, которые были актуальны на момент её вызова? Поясню на примере, что именно я имею ввиду. Код такой:
Код
sec=<код бумаги>
function main()
local function SetLoaded()
loaded = true
end
loaded = false
file = io.open("output.txt", "w+t")
ds = CreateDataSource("TQBR", sec, INTERVAL_M15)
ds:SetUpdateCallback(SetLoaded)
sec_name = getSecurityInfo("TQBR", sec).short_name
file:write("name: "..sec_name)
repeat sleep(1) until loaded
s=ds:Size()
file:write(" size: "..s)
ds:Close()
file:close()
end
Так вот, если 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 и пойти по жизни дальше? (как отличить ситуацию продолжения ожидания данных с сервера от ситуации отсутствия данных?)
Sergey Gorokhov пишет: Здравствуйте, Вопрос уже многократно поднимался на форуме. Ответ: никак.
Прошу понять, что прочитать весь форум довольно затруднительно, а поиском не всегда находится нужное. Поэтому ещё вопрос - а планируется ли добавление срабатывания callback'а в такой ситуации? Ведь это решило бы проблему.
Sergey Gorokhov пишет: Здравствуйте, Вопрос уже многократно поднимался на форуме. Ответ: никак.
Прошу понять, что прочитать весь форум довольно затруднительно, а поиском не всегда находится нужное. Поэтому ещё вопрос - а планируется ли добавление срабатывания callback'а в такой ситуации? Ведь это решило бы проблему.
Вы не совсем понимаете. Дело в том, что нет такого критерия который позволил бы отличить ситуацию "продолжения ожидания" от "отсутствия данных", а значит и решить эту проблему нельзя.
Sergey Gorokhov пишет: Вы не совсем понимаете. Дело в том, что нет такого критерия который позволил бы отличить ситуацию "продолжения ожидания" от "отсутствия данных", а значит и решить эту проблему нельзя.
Хорошо, я допускаю, что интерфейс клиент-сервер не позволяет сделать в этом месте элегантное решение. Но ситуация на мой взгляд требует улучшения, поэтому следующие возможные предложения: 1) Можно ли добавить функцию NUMBER getDataCount(STRING class_code, STRING sec_code, NUMBER interval, [, STRING param]) которая бы сообщала сколько на данный момент есть данных на сервере для данного инструмента? (подозреваю, что отличие будет только COUNT в SQL запросе, но повысит нагрузку на сервер...) 2) Или же добавить функции getSecurityInfo() ещё один возвращаемый параметр. По хорошему конечно дату-время последней известной серверу сделки. Но думаю это не впишется в архитектуру клиент-серверных вызовов. Поэтому может не очень элегантно, но зато просто и надёжно - true-false параметр указывающий были ли сделки до начала сегодняшней торговой сессии. Выглядит может и не очень красиво, но я уверен, что это решит 99% случаев возникновения моего вопроса.
Поверьте эта тема уже миллион раз подымалась, на каждое предложение всегда найдется контр аргумент. И наше обсуждение заведомо ни к чему не приведет.
Цитата
Passport пишет: 1) Можно ли добавить функцию NUMBERgetDataCount(STRING class_code, STRING sec_code, NUMBER interval, [, STRING param]) которая бы сообщала сколько на данный момент есть данных на сервере для данного инструмента? (подозреваю, что отличие будет только COUNT в SQL запросе, но повысит нагрузку на сервер...)
Такая функция уже есть называется Size, однако она ведь не решает проблему не так ли?
Цитата
Passport пишет: Или же добавить функции getSecurityInfo() ещё один возвращаемый параметр. По хорошему конечно дату-время последней известной серверу сделки
Это уже есть, смотрите параметр time из ТТП, однако и она не решает проблему не так ли?
Цитата
Passport пишет: Поэтому может не очень элегантно, но зато просто и надёжно - true-false параметр указывающий были ли сделки до начала сегодняшней торговой сессии
Это уже есть, достаточно посмотреть на график. Но и это не является решением.
Цитата
Passport пишет: Выглядит может и не очень красиво, но я уверен, что это решит 99% случаев возникновения моего вопроса.
Sergey Gorokhov пишет: Здравствуйте, Вопрос уже многократно поднимался на форуме. Ответ: никак.
Прошу понять, что прочитать весь форум довольно затруднительно, а поиском не всегда находится нужное. Поэтому ещё вопрос - а планируется ли добавление срабатывания callback'а в такой ситуации? Ведь это решило бы проблему.
Вы не совсем понимаете. Дело в том, что нет такого критерия который позволил бы отличить ситуацию "продолжения ожидания" от "отсутствия данных", а значит и решить эту проблему нельзя.
Вопрос действительно многократно поднимался на этом форуме. И в этой теме было показано, что есть решение, которое "позволило бы отличить ситуацию "продолжения ожидания" от "отсутствия данных" при наличии этих данных на сервере. Вы не смогли аргументированно опровергнуть данное решение. Поэтому, правильней было бы говорить не об отсутствии критерия, как такового, а об отсутствии желания что либо делать в этом месте.
Надо делать так, как надо. А как не надо - делать не надо.
Sergey Gorokhov пишет: а как отличить что это не одно и тоже?
Э... что значит как отличить?... Size() показывает размер таблицы данных, уже полученных с сервера. Идея функции getDataCount, которую я предложил, в том, чтобы делать запрос на сервер и возвращать количество строк из серверной таблицы. Разница кардинальная, как я понимаю клиент-серверные операции.
Sergey Gorokhov пишет: Дело в том, что нет такого критерия который позволил бы отличить ситуацию "продолжения ожидания" от "отсутствия данных", а значит и решить эту проблему нельзя.
А почему бы не сделать дополнительную функцию, при вызове которой будет возвращаться количество свечей, которое было на сервере по заданному инструменту на момент вызова этой функции? Она отрабатывала бы намного быстрей, чем CreateDataSource, т.к. не требовалось бы передавать весь массив свечей на терминал. Вызвав ее, мы смогли бы узнать, какое минимальное количество свечей должна вернуть нам CreateDataSource. И, самое главное, эта функция всегда возвращала бы нам какое-то определенное значение, даже если свечей по данному инструменту на сервере нет. Если при вызове этой новой функции мы получим 0, то будем знать, что нет смысла ждать поступления каких-либо данных. Таким образом, проблема бесконечного ожидания была бы устранена на 100%. По-моему, нет ничего невозможного в реализации такой функции. Прошу зарегистрировать соответствующее пожелание на доработку.
Старатель пишет: TIME возвращает время последней сделки, но не дату, не так ли?
На графике есть
Пока последняя свечка не загрузится, мы об этом не узнаем.
Но ваш спор не понятен: Вас просят, сказать сколько свечек на сервере. Вы предлагаете считать свечки на рабочем месте. Вас спрашивают о дате-времени последней сделки, чтобы узнать загрузился ли график. Вы предлагаете дождаться загрузки графика, чтобы узнать дату-время последней сделки.
Надо делать так, как надо. А как не надо - делать не надо.
попробую добавить свою ложку в вашу бочку. ------------------------------------- Полагаю, что речь идет о реальном времени. Т е рассмотрим реальную торговлю, а иначе нет смысла вообще в этой дискуссии. ---------------------------------------------------- Обмен сообщениями сервера и терминалов осуществляется асинхронно. Свечи идут от сервера синхронно с неопределенность в одну сделку и один тайм. Свечи формирует сервер на основе двух условий - тайма и события(сделки внутри тайма). Следовательно какая очередная свеча должна быть, мы знаем и без сервера (если время у нас точное) ------------------------------------------------ Если свечи нет, то либо время не то, либо нет событий. Свечи - это нелинейное сжатие данных задним числом. Т е свеча всегда есть , когда пройдут все события включаемые в нее и завершиться тайм. ------------------------- Поэтому на стороне терминала невозможно знать точно текущее состояние на сервере(т е на бирже) Запрашивать сервер о количестве свечей не имеет смысла, так как мы это знаем с точностью до последней свечи (последнего тайма и последней сделки)
Николай Камынин пишет: Полагаю, что речь идет о реальном времени. Т е рассмотрим реальную торговлю, а иначе нет смысла вообще в этой дискуссии.
Цитата
Николай Камынин пишет: Запрашивать сервер о количестве свечей не имеет смысла,
По-моему, Вы не вникли в смысл темы, которая обсуждалась выше. Речь идет о получении истории свечей при первоначальном вызове CreateDataSource (которая обычно достигает 3000 свечей за прошлые дни, плюс сегодняшние свечи). Этот процесс занимает неопределенное время (особенно при одновременном открытии источников данных по нескольким инструментам), а скрипт должен ждать окончания загрузки данных. Прежде всего нам нужно знать, есть ли вообще такая история на сервере. Если на момент вызова CreateDataSource на сервере нет ни одной свечи, то мы можем ждать бесконечно долго пока функция Size() вернет значение, большее 0, или придет коллбэк. Смысл запрашивать количество свечей на сервере есть, и он состоит в том, чтобы избежать подобных ситуаций.
Николай Камынин пишет: Полагаю, что речь идет о реальном времени.
Нет, речь не всегда идёт о реальном времени. Поэтому и все ваши остальные выкладки не всегда верны. Мне необязательно знать данные за последние полчаса, чтобы принять решение на основании данных за предыдующую неделю.
Пардон, действительно, нет надобности обновлять историю которая уже есть в терминале. Было бы хорошо, если бы история в терминале в начале сессии не обновлялась, а добавлялась.
Николай Камынин пишет: действительно, нет надобности обновлять историю которая уже есть в терминале. Было бы хорошо, если бы история в терминале в начале сессии не обновлялась, а добавлялась.
Специально проверил: На выходных с помощью QMinEditor изменил значение одной свечи на графике. Сегодня подключился к серверу, и свеча не обновилась.
Причём, если график не открыт в терминале, то значения "старых" свечей мы получаем только в колбеке (не зависимо, сохранён кэш графиков или нет). Если график открыт, то "старые" свечи возвращаются в CreateDataSource. Эту информацию можно добавить в документацию.
Но в любом случае, значение изменённой свечи не обновляется.
Надо делать так, как надо. А как не надо - делать не надо.
Старатель пишет: Причём, если график не открыт в терминале, то значения "старых" свечей мы получаем только в колбеке (не зависимо, сохранён кэш графиков или нет). Если график открыт, то "старые" свечи возвращаются в CreateDataSource.
То есть если график не открыт, то CreateDataSource вообще не выдаст нам свечи, сохраненные в кэше?
Дмитрий пишет: То есть если график не открыт, то CreateDataSource вообще не выдаст нам свечи, сохраненные в кэше?
Нет, не так. Конечно, CreateDataSource вернёт нам свечи из кэша (я не совсем верно написал выше). Но, если график открыт, то значения свечей мы можем получить сразу. Если же график не открыт, то сначала ds:Size() = 0. Свечи придут позже.
Надо делать так, как надо. А как не надо - делать не надо.
Sergey Gorokhov пишет: Дело в том, что нет такого критерия который позволил бы отличить ситуацию "продолжения ожидания" от "отсутствия данных", а значит и решить эту проблему нельзя.
А почему бы не сделать дополнительную функцию, при вызове которой будет возвращаться количество свечей, которое было на сервере по заданному инструменту на момент вызова этой функции? Она отрабатывала бы намного быстрей, чем CreateDataSource, т.к. не требовалось бы передавать весь массив свечей на терминал. Вызвав ее, мы смогли бы узнать, какое минимальное количество свечей должна вернуть нам CreateDataSource. И, самое главное, эта функция всегда возвращала бы нам какое-то определенное значение, даже если свечей по данному инструменту на сервере нет. Если при вызове этой новой функции мы получим 0, то будем знать, что нет смысла ждать поступления каких-либо данных. Таким образом, проблема бесконечного ожидания была бы устранена на 100%. По-моему, нет ничего невозможного в реализации такой функции. Прошу зарегистрировать соответствующее пожелание на доработку.
Здравствуйте!
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.