CreateDataSource

Страницы: Пред. 1 2 3 След.
RSS
CreateDataSource
 
Пожалуйста без флуда.
Если что, на форуме можно отправлять личные сообщения.
 
Цитата
Sergey Gorokhov пишет:
Пожалуйста без флуда.
Вам бы модератора на форум.  :!:  Злобного.  :evil:

А что касается моих сообщений #40 и #42. Ответите?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Куда попадут данные (1), (2) и (3)?
Колбеки в QUIK идут в основном потоке терминала, поэтому никаких "тут приходят данные" просто не будет.
 
Цитата
Старатель пишет:
Раз уж тут у нас получился "Вечер откровений" касательно работы функции 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) другое
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Имеется ввиду, где эти данные будут обработаны?
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?
Только текущие.
Цитата
Старатель пишет:
Что-нибудь изменится, если колбек задать после обработки таблицы в цикле?
нет не изменится.
 
Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
Вы можете однозначно ответить все ли данные (1), (2) и (3) будут обработаны в колбеке GetPrice, заданном в SetUpdateCallback?
Только текущие.
Не знаю, что вы подразумеваете под словом "текущие", но основываясь на том, что очередь находится на сервере (блин, ну почему нельзя было сразу об этом сказать?!), я делаю вывод, что данные (1), (2) и (3) будут обработаны функцией-колбеком GetPrice()
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
Вы можете однозначно ответить все ли данные (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 всегда равны нулю?
Потому что вы смотрите регулярный таймфрейм.  Переключитесь на тики.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Николай Камынин, вы написали не в тему. Но это не важно: ответ на вопрос об очереди колбеков я уже получил.

Цитата
s_mike@rambler.ru пишет:
Переключитесь на тики.
Переключился на тиковый интервал: секунды появились. Но милисекунды не транслируются.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Николай Камынин , вы написали не в тему. Но это не важно: ответ на вопрос об очереди колбеков я уже получил.
Цитата
s_mike@rambler.ru пишет:
Переключитесь на тики.
Переключился на тиковый интервал: секунды появились. Но милисекунды не транслируются.
А теперь переключитесь с демо спота  на демо фортс или на боевые торги.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Цитата
s_mike@rambler.ru пишет:
Цитата
Старатель пишет:
Переключился на тиковый интервал: секунды появились. Но милисекунды не транслируются.
А теперь переключитесь с демо спотана демо фортс или на боевые торги.
Я имел ввиду для параметров из ТТП. На боевом сервере мс не транслируются для параметров.

Ещё такой вопрос.
Код
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

Можете объяснить результаты?
Надо делать так, как надо. А как не надо - делать не надо.
 
up
Цитата
Старатель пишет:
На боевом сервере мс не транслируются для параметров.
Цитата
Старатель пишет:
Можете объяснить результаты?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Цитата
s_mike@rambler.ru пишет:
Цитата
Старатель пишет:
Переключился на тиковый интервал: секунды появились. Но милисекунды не транслируются.
А теперь переключитесь с демо спотана демо фортс или на боевые торги.
Я имел ввиду для параметров из ТТП. На боевом сервере мс не транслируются для параметров.

Ещё такой вопрос.
Код
 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 пишет:
Цитата
Старатель пишет:
Цитата
s_mike@rambler.ru пишет:
Цитата
Старатель пишет:
Переключился на тиковый интервал: секунды появились. Но милисекунды не транслируются.
А теперь переключитесь с демо спотана демо фортс или на боевые торги.
Я имел ввиду для параметров из ТТП. На боевом сервере мс не транслируются для параметров.

Ещё такой вопрос.
Код
  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-потоками так и не сделан.
 
Цитата
Sergey Gorokhov пишет:
Ошибка будет исправлена в одной из следующих версий программы.
О какой именно ошибке идёт речь?

1)
Цитата
Старатель пишет:
для параметров из ТТП. На боевом сервере мс не транслируются для параметров.
2) или tDS:Close() ?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Цитата
Sergey Gorokhov пишет:
Ошибка будет исправлена в одной из следующих версий программы.
О какой именно ошибке идёт речь?

1)
Цитата
Старатель пишет:
для параметров из ТТП. На боевом сервере мс не транслируются для параметров.
2) или tDS:Close() ?
Добрый день.

Речь идет о том, что DS:Close выдает некорректные результаты.
 
Цитата
Старатель пишет:
Раз уж тут у нас получился "Вечер откровений" касательно работы функции 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 и пойти по жизни дальше? (как отличить ситуацию продолжения ожидания данных с сервера от ситуации отсутствия данных?)
 
Цитата
Passport пишет:
как отличить ситуацию продолжения ожидания данных с сервера от ситуации отсутствия данных?
Здравствуйте,
Вопрос уже многократно поднимался на форуме.
Ответ: никак.
 
Цитата
Sergey Gorokhov пишет:
Здравствуйте,
Вопрос уже многократно поднимался на форуме.
Ответ: никак.
Прошу понять, что прочитать весь форум довольно затруднительно, а поиском не всегда находится нужное.
Поэтому ещё вопрос - а планируется ли добавление срабатывания callback'а в такой ситуации? Ведь это решило бы проблему.
 
Цитата
"Passport пишет:
Цитата
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 пишет:
Цитата
"Passport пишет:
Цитата
Sergey Gorokhov пишет:
Здравствуйте,
Вопрос уже многократно поднимался на форуме.
Ответ: никак.
Прошу понять, что прочитать весь форум довольно затруднительно, а поиском не всегда находится нужное.
Поэтому ещё вопрос - а планируется ли добавление срабатывания callback'а в такой ситуации? Ведь это решило бы проблему.
Вы не совсем понимаете. Дело в том, что нет такого критерия который позволил бы отличить ситуацию "продолжения ожидания" от "отсутствия данных", а значит и решить эту проблему нельзя.
Вопрос действительно многократно поднимался на этом форуме. И в этой теме было показано, что есть решение, которое "позволило бы отличить ситуацию "продолжения ожидания" от "отсутствия данных" при наличии этих данных на сервере. Вы не смогли аргументированно опровергнуть данное решение.
Поэтому, правильней было бы говорить не об отсутствии критерия, как такового, а об отсутствии желания что либо делать в этом месте.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Sergey Gorokhov пишет:
Такая функция уже есть называется Size, однако она ведь не решает проблему не так ли?
Size() возвращает текущее количество свечек на локальном месте, а не на сервере, не так ли?
Цитата
Sergey Gorokhov пишет:
Это уже есть, смотрите параметр time из ТТП, однако и она не решает проблему не так ли?
TIME возвращает время последней сделки, но не дату, не так ли?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Цитата
Sergey Gorokhov пишет:
Такая функция уже есть называется Size, однако она ведь не решает проблему не так ли?
Size() возвращает текущее количество свечек на локальном месте, а не на сервере, не так ли?
а как отличить что это не одно и тоже?
Цитата
Старатель пишет:
TIME возвращает время последней сделки, но не дату, не так ли?
На графике есть
 
Цитата
Sergey Gorokhov пишет:
а как отличить что это не одно и тоже?
Э... что значит как отличить?...
Size() показывает размер таблицы данных, уже полученных с сервера.
Идея функции getDataCount, которую я предложил, в том, чтобы делать запрос на сервер и возвращать количество строк из серверной таблицы.
Разница кардинальная, как я понимаю клиент-серверные операции.
Цитата
Sergey Gorokhov пишет:
На графике есть
Так кажется идея функции CreateDataSource отчасти и состояла изначально в том, чтобы избавиться от графика, если он не нужен...
 
Цитата
Sergey Gorokhov пишет:
Дело в том, что нет такого критерия который позволил бы отличить ситуацию "продолжения ожидания" от "отсутствия данных", а значит и решить эту проблему нельзя.
А почему бы не сделать дополнительную функцию, при вызове которой будет возвращаться количество свечей, которое было на сервере по заданному инструменту на момент вызова этой функции?
Она отрабатывала бы намного быстрей, чем CreateDataSource, т.к. не требовалось бы передавать весь массив свечей на терминал.
Вызвав ее, мы смогли бы узнать, какое минимальное количество свечей должна вернуть нам CreateDataSource.
И, самое главное, эта функция всегда возвращала бы нам какое-то определенное значение, даже если свечей по данному инструменту на сервере нет.
Если при вызове этой новой функции мы получим 0, то будем знать, что нет смысла ждать поступления каких-либо данных. Таким образом, проблема бесконечного ожидания была бы устранена на 100%.
По-моему, нет ничего невозможного в реализации такой функции.
Прошу зарегистрировать соответствующее пожелание на доработку.
 
Цитата
Sergey Gorokhov пишет:
а как отличить что это не одно и тоже?
Вопрос не понятен.
Цитата
Старатель пишет:
Size() возвращает текущее количество свечек на локальном месте
- это факт. Нужны какие-либо доказательства?
Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
TIME возвращает время последней сделки, но не дату, не так ли?
На графике есть
Пока последняя свечка не загрузится, мы об этом не узнаем.

Но ваш спор не понятен:
Вас просят, сказать сколько свечек на сервере. Вы предлагаете считать свечки на рабочем месте.
Вас спрашивают о дате-времени последней сделки, чтобы узнать загрузился ли график. Вы предлагаете дождаться загрузки графика, чтобы узнать дату-время последней сделки.
Надо делать так, как надо. А как не надо - делать не надо.
 
Дмитрий, спасибо за поддержку, именно это, я и имел ввиду, когда предлагал функцию getDataCount в сообщении #84
 
попробую добавить свою ложку в вашу бочку.
-------------------------------------
Полагаю, что речь идет о реальном времени.
Т е рассмотрим реальную торговлю, а иначе нет смысла вообще в этой дискуссии.
----------------------------------------------------
Обмен сообщениями сервера и терминалов осуществляется асинхронно.
Свечи идут от сервера синхронно с неопределенность в одну сделку и один тайм.
Свечи формирует сервер на основе двух условий - тайма и события(сделки внутри тайма).
Следовательно какая очередная свеча должна быть, мы знаем и без сервера (если время у нас точное)
------------------------------------------------
Если свечи нет, то либо время не то, либо нет событий.
Свечи - это нелинейное сжатие данных задним числом.
Т е свеча всегда есть , когда пройдут все события включаемые в нее и завершиться тайм.
-------------------------
Поэтому на стороне терминала невозможно знать точно текущее состояние на сервере(т е на бирже)
Запрашивать сервер о количестве свечей не имеет смысла,
так как мы это знаем с точностью до последней свечи (последнего тайма и последней сделки)
 
Цитата
Николай Камынин пишет:
Полагаю, что речь идет о реальном времени.
Т е рассмотрим реальную торговлю, а иначе нет смысла вообще в этой дискуссии.
Цитата
Николай Камынин пишет:
Запрашивать сервер о количестве свечей не имеет смысла,
По-моему, Вы не вникли в смысл темы, которая обсуждалась выше.
Речь идет о получении истории свечей при первоначальном вызове CreateDataSource (которая обычно достигает 3000 свечей за прошлые дни, плюс сегодняшние свечи). Этот процесс занимает неопределенное время (особенно при одновременном открытии источников данных по нескольким инструментам), а скрипт должен ждать окончания загрузки данных.
Прежде всего нам нужно знать, есть ли вообще такая история на сервере.
Если на момент вызова CreateDataSource на сервере нет ни одной свечи, то мы можем ждать бесконечно долго пока функция Size() вернет значение, большее 0, или придет коллбэк.
Смысл запрашивать количество свечей на сервере есть, и он состоит в том, чтобы избежать подобных ситуаций.
 
Цитата
Николай Камынин пишет:
Полагаю, что речь идет о реальном времени.
Нет, речь не всегда идёт о реальном времени. Поэтому и все ваши остальные выкладки не всегда верны.
Мне необязательно знать данные за последние полчаса, чтобы принять решение на основании данных за предыдующую неделю.
 
Пардон,
действительно,
нет надобности обновлять историю которая уже есть в терминале.
Было бы хорошо,
если бы история в терминале в начале сессии  не обновлялась,
а добавлялась.
 
Цитата
Николай Камынин пишет:
действительно,
нет надобности обновлять историю которая уже есть в терминале.
Было бы хорошо,
если бы история в терминале в начале сессии не обновлялась,
а добавлялась.
Специально проверил:
На выходных с помощью QMinEditor изменил значение одной свечи на графике. Сегодня подключился к серверу, и свеча не обновилась.

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

Но в любом случае, значение изменённой свечи не обновляется.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Причём, если график не открыт в терминале, то значения "старых" свечей мы получаем только в колбеке (не зависимо, сохранён кэш графиков или нет). Если график открыт, то "старые" свечи возвращаются в CreateDataSource.
То есть если график не открыт, то CreateDataSource вообще не выдаст нам свечи, сохраненные в кэше?
 
Цитата
Дмитрий пишет:
То есть если график не открыт, то CreateDataSource вообще не выдаст нам свечи, сохраненные в кэше?
Нет, не так. Конечно, CreateDataSource вернёт нам свечи из кэша (я не совсем верно написал выше). Но, если график открыт, то значения свечей мы можем получить сразу.
Если же график не открыт, то сначала ds:Size() = 0. Свечи придут позже.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Дмитрий пишет:
Цитата
Sergey Gorokhov пишет:
Дело в том, что нет такого критерия который позволил бы отличить ситуацию "продолжения ожидания" от "отсутствия данных", а значит и решить эту проблему нельзя.
А почему бы не сделать дополнительную функцию, при вызове которой будет возвращаться количество свечей, которое было на сервере по заданному инструменту на момент вызова этой функции?
Она отрабатывала бы намного быстрей, чем CreateDataSource, т.к. не требовалось бы передавать весь массив свечей на терминал.
Вызвав ее, мы смогли бы узнать, какое минимальное количество свечей должна вернуть нам CreateDataSource.
И, самое главное, эта функция всегда возвращала бы нам какое-то определенное значение, даже если свечей по данному инструменту на сервере нет.
Если при вызове этой новой функции мы получим 0, то будем знать, что нет смысла ждать поступления каких-либо данных. Таким образом, проблема бесконечного ожидания была бы устранена на 100%.
По-моему, нет ничего невозможного в реализации такой функции.
Прошу зарегистрировать соответствующее пожелание на доработку.
Здравствуйте!

Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Страницы: Пред. 1 2 3 След.
Читают тему
Наверх