Nikolay (Все сообщения пользователя)

limit_kind NUMBER Срок расчётов.

Возможные значения: положительные целые числа,  начиная с «0», соответствующие срокам расчётов из таблицы  «Позиции по инструментам»: «0» – T0, «1» – T1, «2» – T2 и т.д.

Для получения значений параметров таблицы «Клиентский портфель» для клиентов срочного рынка без единой денежной позиции необходимо  указать в качестве «client_code» – торговый счет на срочном рынке,  а в качестве «limit_kind» – 0.

Вы для своего инструмента уточните срок расчетов, тот и задайте.

Можете также вывести из таблицы depo_limits все строки и посмотреть значения. Позиция для Т2 и Т0 - это могут быть разные значения.

А зачем у Вас Limit_kind = 365?

Руководство по языку qLua говорит нам:
result STRING Результат выполнения операции.

Возможные значения:
«0» – ошибка;

«1» – параметр найден
Можно, конечно, интерпретировать по разному, но, по факту, раз не равно "1", то какой-бы ни был результат в param_value, параметр не найден или не получен.
Либо надо провести дополнительную проверку на корректность ввода параметров инструмента, либо не пытаться угадать что этот 0 будет значить.

Не очень понята проблема. Вам никто не мешает прежде чем получать данные, проверить, что эти данные есть.
Т.к. getParamEx возращает таблицу, то легко проверить есть ли данные, сравнив поле result этой таблицы с литералом '1'.
Если не равно "1", то данных нет, по какой-то причине. Вы их можете привести к 0, через tonumber(...) or 0, но этот 0 будет иметь смысл - данных нет.

Да вроде таких примеров на просторах достаточно. Собственно просто читать поток сделок и что-то с ним делать.

Вот, для примера https://github.com/nick-nh/qlua/tree/master/quantScript

Я бы уточнила так:

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

Впрочем, такие пожелания уже были.

Демо счет, Quik 8.13.0.106

Установлен лимитный ордер. Совершена ручная сделка, исполнившая этот ордер. В таблице сделок номер сделки задублирован.

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

На форуме есть ветка https://forum.quik.ru/forum17/ для произвольного общения.

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

Почти. Этот маркер будет всего лишь триггером на запуск, инициализацию алгоритма. До него считаем, что данные некорректные и смысла на запуск нет вовсе.

При этом остаток данных будет получен уже по факту.

А вот если нет никаких ориентиров, то по той же логике запускаем скрипт, ориентируясь на данные в кеше. Запускаем и... На основании чего будем заявки отправлять: на вчера 23:00, позавчера, сегодня час назад.

Собственно сейчас и приходится формировать алгоритм ожидания для получения потока CreateDataSource, ожидая когда время последнего бара с учетом периода будет больше времени последней сделки. Иначе данные не доехали.

При этом потоки данных, имеющие время в своем составе хоть как-то позволяют организовать оценочное ожидание и проверку (скажем заказ обезличенных сделок так долго поступает, что без ожидания можно подумать, что и потока нет), а вот данные не имеющие его уже никак. А то ведь бывает уже торговая сессия идет, а открытые позиции терминал еще не получил https://forum.quik.ru/messages/forum10/message49888/topic5698/#message49888 И думай - может сделки прошли и позиция закрылась. Но сделок нет. А может они тоже еще не загрузились.

А причем здесь сервер? Сервер дает что попросили.
getParamEx из кеша теримнала данные вернет, если они есть. А если их заказали с сервера, то они будут обновляться в кеш.

А что программа должна делать, если с сервера не получен ответ. Она просто возвращает в поле result возвращаемой таблицы = "0", что условно и соответствует ошибке получения данных. Это он как раз и говорит - ничего нет.
А message - это средство оповещения.

Дебаг - это либо вывод в лог отладочной информации с level = debug. Либо использовать PrintDbgStr. При этом код должен содержать ассерты на входящие данные, чтобы сразу и понять где ошибка.

Питон тоже самое, только тяжелее, медленнее и со своими проблемами.

Что касается клиент серверного взаимодействия, то вне зависимости от языка, прежде чем проводить операции с данными, полученными с сервера, из принято проверять.
Они могут быть не получены, они могут быть некорректными. В вашем примере Вы сразу пытаетесь привести значение к числу, не убедившись, что они есть.
Если вернется что-то не то, tonumber вернет nil. А далее Вы с этим будете арифметические действия выполнять.

Первичные данные всегда актуальны на какой-то конкретный момент времени в  прошлом и очень редко актуальны в течение какого-либо длительного  периода.

Да, актуальность потока данных не контролируется. Но вот на момент заказа вполне (это ведь точная отметка по оси времени). Сколько данных - столько, давай их все и все что будет еще. По приходу данных на момент запроса  - сигнал (для каждого момента до точки заказа колбек мне не нужен),  а далее включай колбек для новых (после точки заказа). Т.е. пошли уже данные потоком. А вот  если мне сыпать колбеки на каждый момент в прошлом (до точки заказа), то, конечно, смысла  нет. Если только не будет отдельного сигнала о достижении данных на момент заказа.

Также вполне может быть сценарий получения данных просто до момента заказа. Скажем - дай, что есть сейчас, на момент прихода заказа. Будущее не интересно. Чем не актуальные данные. Захочу новые - закажу еще.

А я разве сказал, что нет. Вопрос получения данных и их актуальности на этом форуме уже много лет обсуждается. OnParam - это всего лишь какая-то реализация, предложенная разработчиками.

Конечно. Но если говорить о пакетах данных - заказал пакет: получен, не получен.

Даже бесконечный поток реального времени, если разделить на дискретные пакеты, уже позволяет контролировать загрузки пакетов. Иначе один пакет сбойный - толку от такого потока, если это критически важный поток данных.

Владимир, при клиент-серверном взаимодействии таймерное ожидание никаких гарантий не дает. Необходимо либо иметь метод в API дающий ответ, что все загружено, либо колбек по факту события загрузки.

Владимир, предлагаю Вам присоединиться к форуму mfd.ru или smart-lab.ru. Думаю там Вы найдете благодарную публику. На первом форуме очень любят "Гуру".
Здесь, все же, хотелось бы видеть комментарии по существу, без литературных вставок.


Вы написали СЕБЕ скрипт - и ладно. Поучать других малополезное занятие. Когда решите написать скрипт кому-то еще (вдруг случится такое чудо), то, вполне возможно, столкнетесь с тем, что очень у многих пользователей терминал настроен не так как у Вас, брокер другой и он работает не так как ваш. А Ваш скрипт не учитывает это.

Продолжайте в том же духе оформлять свой код - не то еще будет.

Никаких проблем с подачей транзакции и поиском ответов, если он пришел, нет. А то что Вы не знаете что такое счет депо только подтверждает, что предметная область Вами не усвоена.

Велосипеды уже давно написаны, языку уже 27 лет. Не стесняетесь пользоваться http://lua-users.org/wiki/SampleCode, раздел Serialization.

Снимаю замечание. Не увидел изначально переменную seen. Обычно этот вариант не содержит ее.

В этом проблема. Кеширования ссылок нет.

Это довольно распространенный вариант на просторах. Вы попробуйте им вывести Класс или таблицы с перекрестными ссылками.

Вопрос уникальности транзакции обычно возникает в свете поиска ответа на транзакцию и установленного ордера по ней, сделок.
Обычно делают номер как unix_time + mcs*1000. Также скрипт пишет в поле brokerref свой уникальный комментарий. Или, как выше написали, есть некая добавка от номера скрипта.
Я предпочитаю brokerref, т.к. он идет сквозным образом от транзакции в ордер и сделки.

Вместе это дает уникальность при дальнейшем использовании номера и brokerref.

Если id  транзакции предполагается в дальнейшем использовать как ключ, то необходимо обеспечить его уникальность. Хоть рандомизация и повышает вероятность уникальности, но не обеспечивает ее в полной мере.
Чаще всего используют производные от unix-time как ключ транзакции. Но при этом надо еще подумать об уникальности между скриптами, т.к. вероятность отправки транзакции двумя скриптами одновременно есть.

qlua.dll - это библиотека, неотъемлемая от терминала. Так что ее можно считать частью среды исполнения.
Я же говорю о библиотеках реализующие часть функциональности, которую можно реализовать самому. Предпочтение будет всегда тем, которые имеют открытый код.

Владимир, как угодно. Можете доверять чужим рукам.

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

Так что это не о том.

А по существу уже все обсудили. Я слабо себе могу представить разработчика, использующего библиотеки без исходных кодов.

Эти секунды берутся, если установлен флаг "Запрашивать данные раз в".
Если не установлен, то происходит постоянное получение данных, с учетом минимальной допустимой дискретности.

Время лучше всегда и сравнивать в секундах, переведя его в unix-time, используя os.time.
Надо определить переменную, определяющую время 12:00 текущего дня и сравнивать ее с временем таблицы.
Условно:
os.time(trade.datetime) > time_12

Владимир, неужели Вы думаете, что если бы такое было, то за все время существования языка (с 1993 года) это никто не заметил бы? Такого рода проблема (самопроизвольное магическим образом изменение значения переменной) - это просто крест на языке.

Не бывает такого поведения.
Если Вы между индексациями таблицы изменение значение переменной к, то язык здесь не виноват. В случае же первого варианта у Вас нет переменной и нет проблемы.
Часто такое наблюдается при использовании глобальных переменных, когда к, объявленная в одном месте, перезаписывется в другом.

Свечи могут не поступать. Есть такая ошибка (особенность) у серверной части брокера - последняя цена обновляется, а свечи нет. При этом торговая сессия идет. Смотришь на график, не двигается, а цена последней сделки меняется.

Данные стакана, тоже могут не поступать. При этом еще есть планка, когда нет заявок. Есть предторговый аукцион, когда стакан заполнен, а сессия не идет.
Для срочного рынка есть клиринг, когда сессия не идет, а заявки какое-то время еще есть в стакане.

Владимир, я не очень понимаю в чем у Вас проблема с типами. Ее нет. Если Вы записываете в переменную значение другого типа, то это чья проблема?
В других языках получите ошибку компиляции, здесь просто следите за руками.

Кроме быстродействия и наглядности никаких.

То что получение данных таблицы сделано разово - это хорошо, т.к. это затратная по памяти функция.
А вот то, что функция аггрегирования вызывается несколько раз - это не очень.

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

Что касается направления сделки, то если это обычная таблица trades (а не обезличенные сделки), то направление это 2-ой бит флага.
И проверять его лучше логически через функцию bit.test, а не сравнивать с десятичным числом.


if bit.test(trade.flag, 2) then
...

Никаких проблем с брокером Сбербанк не наблюдается.
Формат отправки client_code..'/'..comment

Владимир, разработчики терминала Вам в этом вопросе не помогут.

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

Для проигрывания звуковых файлов Вы можете воспользоваться библиотекой w32:
https://quik2dde.ru/viewtopic.php?id=78

В данном контексте у нас последний бар = Size. Можно порассуждать о теоретических ситуациях, но зачем.

Я такие задачи предпочитаю решать через замыкание. Но можно, конечно, и переменные создать.

Так я Вам уже написал:

Так расчет будет только для исторических баров при старте. Текущий бар всегда равен Size, а значит и расчета нет.
Когда появится новый бар, он опять равен Size.

Если Вы хотите при поступлении нового бара произвести расчет прошлого бара, то необходимо обеспечить хранение последнего рассчитанного бара он будет равен Size()-1, а при поступлении нового увеличить индекс рассчитанного бара и произвести расчет. Т.о. Вы будете производить расчет последнего закрытого бара.

Так расчет будет только для исторических баров при старте. Текущий бар всегда равен Size, а значит и расчета нет.
Когда появится новый бар, он опять равен Size.
Также Вы переменную sum инициализировали где-то? Иначе будет арифметика с nil.

В Квик нумерация баров идет от 1, в отличии от MT.

Поэтому последний бар равен результату выполнения функции Size(). Она возвращает текущее число баров. Если индекс равен ему, то он последний существующий бар.

За это время брокер уже восстановил данные в потоке данных. При этом в какие-то дни наблюдались частично корректные данные.
В частности для класcа FQBR (иностранные акции) данные были всегда корректны. Для TQBR данные были заполнены по нескольким инструментам, остальные были пустые.
С чем связана такая избирательности не очень понятно.

Не уверен. Разные клиенты.

Опять Финам.




Клиент не хочет отправлять архив рабочего места. Может все же понять, что происходит на сервере брокера.

В голову приходит одно: взять w32 и поискать главное окно. Если найдено  на английском, то english. Правда, если несколько терминалов, то уже  может быть не вариант.

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

Кстати, забыл уточнить, на срочной секции все корректно, параметры заполнены.

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

С начала этой недели у брокера Сбербанк данные PRICEMIN, PRICEMAX нулевые. Сам брокер ничего внятного сказать не может.

Если имеется ввиду версия lua, то есть предопределенная глобальная константа _VERSION.

Если есть интерфейс у скрипта, ставить задержку меньше 50млс не рекомендуется.
А если поставить 0, то по идее влиять не должно, раз у нас много ядер, но Квик все же "висит". Поэтому хоть что-то да лучше поставить.