ParamRequest и getParamEx2

Здравствуйте, Старатель!
Если речь идет исключительно об актуальности данных, то рекомендуем перед тем, как вызывать getParamEx (getParamEx2), сначала вызывать ParamRequest.
Таким образом, после вызова getParamEx (getParamEx2) отобразятся только актуальные данные.

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

Здравствуйте!
Пример (для любого инструмента):

Старатель,
А Вы проверьте.

Старатель,
ParamRequest() это добавление в список ожидаемых заказов. Сам заказ делается раз в период. Т.е. для более-менее успешного получения заказанных параметров нужно подождать.
Для понимания что заказанный параметр начал ехать нужно ждать коллбэк OnParam(), после чего вызывать getParamEx2

Если параметр уже заказан, до запуска скрипта, то getParamEx2 и так получит "актуальные данные" без всяких ParamRequest и OnParam ждать нет нужды.

Sergey Gorokhov, сможете привести однозначный алгоритм получения параметра, который работает всегда и надёжно, и который даёт гарантированно актуальное значение, а не старые данные из кеша? И чтобы не нужно было ждать полдня, пока ожидаемый параметр поменяет своё значение.

Пример с getQuoteLevel2 показателен.
Если вы про аналог функции IsSubscribed_Level_II_Quotes, то она бесполезна, т.к. показывает, что подписка включена в то время когда, данные ещё не получены.
Но дуэт Subscribe_Level_II_Quotes и getQuoteLevel2 самодостаточен и позволяет получать только актуальные данные.
PS: Обратил внимание, что после остановки скрипта, подписка на стакан не закрывается автоматически. Надо бы исправить.

Для ParamRequest и getParamEx2 хотелось бы такой же работы.

Поймите что стакан и ТТТ это кардинально разные таблицы которые обновляются кардинально разными способами.
Нельзя сделать в ТТТ "аналогично" как в стакане.

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

Вот вот, нужно в OnParam помимо клсса и кода передавать список параметров которые изменились, а то их 100+, а какой(е) именно изменился - не понятно.
А getParamEx2 это медленная функция.

swerg,Потому что в роботе хотелось бы получать актуальные данные, т. к. робот используется для автоматизации.

Разное время реакции. Пока трейдер примет решение, котировка поменяется. А скрипт: получил котировку - выполнил действие.

Старатель, Это Вы не в теме.   Скрипт ТОЖЕ не может "выполнить действие" - он может лишь послать заявку, и за это время котировка ТОЖЕ может поменяться. Я вначале собирался ставить в заявку BID или OFFER - как раз для мгновенного исполнения, но потом передумал, ибо это ТОЖЕ ничего не гарантирует. Но для любого тикера всегда существует некий "дребезг", и потому в 99 случаях из 100 заявка по LAST всё равно сработает в течение пары минут, если не секунд, так что работает мой скрипт ТОЛЬКО по LAST и ТОЛЬКО опросом ТТТ. И только за сегодня у него уже есть одна сделка у одного брокера (рублёвая) и шесть сделок у другого (долларовые). ЧТД!

Разное время реакции. Пока трейдер примет решение, котировка поменяется. А скрипт: получил котировку - выполнил действие.[/QUOTE]

Ну т.е. грубо говоря нужен функционал:
1) подписались на новые данные
2) взвели признак (таймер) "позови функцию2" через 1 сек (условный интервал типичной актуализации данных)
3) вышли из функции
4) через секунду считаем, что данные приехали - на этом основании получаем данные и принимаем решение.

Здесь мне видится принципиальным пункт 3), дабы не подвешивать QUIK на sleep() и точно дать ему обработать полученные данные.

Я про то, что QUIK (да и не только) в принципе ведь не позволяет вам узнать актуальные сейчас вы видите данные в терминале или нет. Просто считается что если человек что-то видит - то он принимает на этом основании решение - и это как бы никого не парит (хотя данные могут быть вовсе не актуальными).
А вот при автоматизации почему-то непременно начинает всех волновать актуальность данных.

Так может вопрос лишь в подходе к написанию скрипта?
Я прекрасно понимаю, что хочется писать скрипт максимально просто и прозрачно, я и сам так делаю:
- подписался на данные
- прочитал данные
- вычислил формулы
- принял решение

Но почему я и привожу постоянно аналогии с визуальным получением данных - потому что, вероятно, раз там это все работает и никого не парит - то может вопрос в том, что подход к написанию надежных скриптов надо просто как-то поменять?
Я не знаю точно как. Это всё не "наезд" на вас лично, я просто сам давно маюсь этой темой и высказываю наболевшие мысли вслух в надежде на взаимное обсуждение "Как нам реорганизовать Рабкрин"©.

Описка:

следует читать так:
а) когда данные по подписке прИехали - а толку?

Про время передачи данных по каналам связи ведь все в курсе? Надеюсь вы не это хотите обсудить, а вопрос:
Если последнее, то давайте начнём хотя бы с сообщения #19

Могли бы вы накидать псевдокод как планируете использовать эту новую функцию?

swerg, ну давайте пофантазируем, что в ближайшем десятилетии нам дали такую функцию:
Либо можно возвращать то же значение дополнительным параметром received в таблице, возвращаемой getParamEx2
Значение 0 - можно и не делать, не вижу возможности его использовать. Возможно, и сам клиент, узнаёт об успешности подписки только по факту получения параметра с сервера.
В любом случае, сервер что-то шлёт клиенту (хотя бы дефолтные нули и пустые строки), даже если

Использование:

Скрытый текст

Код function main()   ParamRequest(class_code, sec_code, param_name)   local r = ParameterReceived(class_code, sec_code, param_name)   if r == 2 then     -- Параметр уже был заказан и получен     local param = getParamEx2(class_code, sec_code, param_name)     -- Далее можно сразу работать с этим параметром или ждать колбека     ...   elseif r == 1 then     -- Параметр ещё не получен, ждём колбек   elseif r == 0 or r == nil then     message("Что-то пошло не так", 3)   end end function OnParam(class_code, sec_code)   local r = ParameterReceived(class_code, sec_code, param_name)   if r == 2 then     -- Параметр получен     local param = getParamEx2(class_code, sec_code, param_name)     ...   else     -- Ждём следующий колбек     return   end end Либо то же с использованием параметра в таблице, возвращаемой getParamEx2: Код function main()   ParamRequest(class_code, sec_code, param_name)   local param = getParamEx2(class_code, sec_code, param_name)   if param.received == 2 then     -- Параметр уже был заказан и получен     -- Далее можно сразу работать с этим значением или ждать колбека     ...   elseif param.received == 1 then     -- Параметр ещё не получен, ждём колбек   elseif param.received == 0 or param.received == nil then     message("Что-то пошло не так", 3)   end end function OnParam(class_code, sec_code)   local param = getParamEx2(class_code, sec_code, param_name)   if param.received == 2 then     -- Параметр получен     ...   else     -- Ждём следующий колбек     return   end end

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



Так-то, да, было бы понятней, но боюсь, не все с этим согласятся.

В начале сессии кеш и так очищается, а ежели в течение сессии, да ну нафиг такое решение  

В ТТТ есть следующие поля:
 "TRADE_DATE_CODE" - дата торгов
"TIME"  -  время последней сделки (с точностью до секунды)

По-хорошему, во всех записях обмена с сервером следовало бы иметь служебные поля <Дата и время передачи с точностью до млсек.> и <Дата и время приема с точностью до млсек.>, заполняемые соответствующими сторонами в момент приема/передачи таких записей.  Эти поля должны быть доступны пользователю.

Добрый день.

ParamRequest будет корректно работать, если вручную в таблицу текущих торгов будет добавлен нужный параметр.
ParamRequest() это добавление в список ожидаемых заказов.

Для понимания что заказанный параметр начал ехать нужно реализовать коллбэк OnParam()

Нет.