Замечания по реализации в QUIKе обработки заявок (и, наверное стоп-заявок).
Пользователь
Сообщений: Регистрация: 12.05.2020
05.06.2025 12:55:21
1. trans_id известен в момент подачи заявки, но в таблице orders поле trans_id в записи заявки формируется с задержкой. Это приводит к тому, что при обращении к существующей записи таблицы orders возможны случаи отсутствие значения trans_id. Не видно никаких проблем в том чтобы поле trans_id формировалось в момент создания записи в таблице orders. Почему так не сделано?
2. Бывали случаи (сразу после снятия заявки), когда при чтении существующей записи: order = getItem_wait('orders', Индекс_существующей_записи) значение order равно nil. "Костыль" на такие ситуации следующий:
Код
local function getItem_wait(tbl_quik, ind)
local ob = getItem(tbl_quik, ind)
local N = 500
while not ob do
sleep(10)
ob = getItem(tbl_quik, ind)
N = N - 1
if N <= 0 then error ('Не дождались результата чтения таблицы ' .. tbl_quik .. ' по индексу ' .. tostring(ind)) end
end
return ob
end
Предлагается тело функции getItem_wait в каком то виде реализовать в штатной функции getItem.
Пользователь
Сообщений: Регистрация: 20.03.2023
05.06.2025 14:42:35
В доках не написано, но на сколько я понимаю, в SearchItems синхронизирован доступ к таблицам из разных потоков, в отличие от остальных функций доступа, поэтому может быть такой эффект от getItem
Пользователь
Сообщений: Регистрация: 30.01.2015
06.06.2025 07:41:12
Возможно, причина в том, что запись в таблицу заявок производится после выхода из колбека. Поэтому, если обратится к таблице заявок в колбеке, то там будут старые данные. Т е при снятии заявки в таблице заявка будет еще активной, а в колбеке - пассивной.
Пользователь
Сообщений: Регистрация: 12.05.2020
06.06.2025 08:06:25
Цитата
nikolz написал: Возможно, причина в том, что запись в таблицу заявок производится после выхода из колбек
Причина мне не интересна. Я написал как сделать так, чтобы у пользователей было меньше вопросов.
1. Отсутствие trans_id на исходной записи заявки - корректное поведение. Причины обсуждались на форуме ранее, рекомендуем ознакомиться, например, с .
2. По предоставленному описанию не смогли воспроизвести подобную проблему при вызове функции getItem. Просим Вас более подробно описать воспроизведение, а также сообщить используемую версию терминала QUIK. Информацию можно направить на нашу почту - в этом случае просим указать в письме ссылку на данную тему форума.
Пользователь
Сообщений: Регистрация: 12.05.2020
16.06.2025 14:27:32
Цитата
Anton Belonogov написал: По предоставленному описанию не смогли воспроизвести подобную проблему при вызове функции getItem.
Эта ситуация "плавающая" (я ее увидел один раз, но с распечатанными параметрами доступа к таблице), связанная, возможно, с синхронизацией доступа к записям таблицы. У меня нет кода стабильно воспроизводящего эту ситуацию.
Цитата
Anton Belonogov написал: 1. Отсутствие trans_id на исходной записи заявки - корректное поведение. Причины обсуждались на форуме ранее, рекомендуем ознакомиться, например, с этой темой .
Я знаком с этим обсуждением. Там объясняется как сделано сейчас. Но зачем и на основании чего выполняется запись в таблицу заявок без trans_id? Если на основании созданной пользователем транзакции, то в ней trans_id есть.
1. Если удастся уточнить условия воспроизведения проблемы, просим сообщить нам. Дополнительно рекомендуем использовать актуальную версию Рабочего места QUIK (на данный момент - 12.4.0).
2. Транзакция и заявка - разные сущности, которые передаются по разным каналам, и сервер QUIK в свою очередь определяет, что эти сущности связаны, заполняя на заявке trans_id и другие параметры. Для ускорения передачи информации сервер изначально может отправлять заявки без заполненного trans_id, это не является ошибкой. Все это было подробно описано в теме, указанной в нашем предыдущем ответе, и в предшествующей ей аналогичной теме.
Пользователь
Сообщений: Регистрация: 12.05.2020
18.06.2025 08:41:23
Цитата
Anton Belonogov написал: Для ускорения передачи информации сервер изначально может отправлять заявки без заполненного trans_id, это не является ошибкой.
Что может делать в скрипте пользователь с заявкой без заполненного trans_id? ----- Есть по крайней мере два варианта реализации того, чтобы пользователь получал заявку всегда с trans_id. 1. Счетчик выдаваемый функцией getNumberOf увеличивается только после заполнения trans_id. 2. Для формирования записей заявок создается буфер, в котором все делается как сейчас в таблице, но записи из буфера сохраняются в таблице заявок только после заполнения trans_id.
Заявка изначально присылается без trans_id для ускорения передачи данных. Описанные изменения негативным образом скажутся на скорости получения информации терминалом.
При получении в скрипте заявки с trans_id следует ожидать поступления обновления записи с уже заполненным параметром.
Пользователь
Сообщений: Регистрация: 12.05.2020
18.06.2025 12:26:44
Цитата
Anton Belonogov написал: Описанные изменения негативным образом скажутся на скорости получения информации терминалом.
1. Зачем пользователю быстро видеть "сырые" данные, которые нельзя использовать непосредственно в своем скрипте? 2. Сам факт многократного обсуждения данной темы пользователями показывает, что в обработке заявок есть проблема. Пользователю все равно приходится выполнять ту работу, которая не реализована разработчиком QUIK, а именно, писать фрагмент учитывающий и обрабатывающий записи заявок без trans_id. Где тут скорость?
Пользователь
Сообщений: Регистрация: 27.01.2017
18.06.2025 13:24:02
Судя по всему речь про реализацию колбеков как таковую. Сейчас - это просто триггер на любое изменение, без фильтров, что максимально быстро. А если делать фильтры, то уже всё усложняется - какие фильтры, почему такие, а не иные и т.д.
В этом плане для пользователя было бы хорошо иметь реализацию организации своего колбека. Например, того же OnParam, но своего. Текущий - это пожиратель ресурсов. Например, хочу иметь колбек на изменения таблицы текущих торгов с фильтрами по коду, классу инструментов и заданному списку параметров.
Что-то типа такого:
local on_param = SubscribeOnParam({'SBER', 'GAZP', 'SiU5'}, {'LAST', 'BID', 'OFFER'})
Т.е. мне не интересны другие коды и параметры. И таких подписок делать много, вплоть до одного инструмента, параметра.
Пусть эта реализация будет внутри терминала, и не влияющая на получение информации. Например, поток данных заходит в очередь, а сформированные колбеки её разбирают. Желательно отдельным потоком. И так для любых таблиц терминала.
Но это, как говорится, совсем другая задача. Кодировка до сих пор 1251, чего уж говорить об этом.
написал: Описанные изменения негативным образом скажутся на скорости получения информации терминалом.
1. Зачем пользователю быстро видеть "сырые" данные, которые нельзя использовать непосредственно в своем скрипте? 2. Сам факт многократного обсуждения данной темы пользователями показывает, что в обработке заявок есть проблема. Пользователю все равно приходится выполнять ту работу, которая не реализована разработчиком QUIK, а именно, писать фрагмент учитывающий и обрабатывающий записи заявок без trans_id. Где тут скорость?
Почему данные нельзя использовать? К примеру, если предполагается, что есть единственный скрипт, работающий с инструментом - все заявки его, trans_id вообще может быть неинтересен.
Пользователь
Сообщений: Регистрация: 12.05.2020
19.06.2025 09:49:33
Цитата
paluke написал: К примеру, если предполагается, что есть единственный скрипт, работающий с инструментом - все заявки его, trans_id вообще может быть неинтересен.
С этим частным случаем можно согласиться, но все таки QUIK не "живопырка", используемая только в этом частном случае.
Пользователь
Сообщений: Регистрация: 30.01.2015
20.06.2025 10:55:22
Цитата
Nikolay написал: Судя по всему речь про реализацию колбеков как таковую. Сейчас - это просто триггер на любое изменение, без фильтров, что максимально быстро. А если делать фильтры, то уже всё усложняется - какие фильтры, почему такие, а не иные и т.д.
В этом плане для пользователя было бы хорошо иметь реализацию организации своего колбека. Например, того же OnParam, но своего. Текущий - это пожиратель ресурсов. Например, хочу иметь колбек на изменения таблицы текущих торгов с фильтрами по коду, классу инструментов и заданному списку параметров.
Что-то типа такого:
local on_param = SubscribeOnParam({'SBER', 'GAZP', 'SiU5'}, {'LAST', 'BID', 'OFFER'})
Т.е. мне не интересны другие коды и параметры. И таких подписок делать много, вплоть до одного инструмента, параметра.
Пусть эта реализация будет внутри терминала, и не влияющая на получение информации. Например, поток данных заходит в очередь, а сформированные колбеки её разбирают. Желательно отдельным потоком. И так для любых таблиц терминала.
Но это, как говорится, совсем другая задача. Кодировка до сих пор 1251, чего уж говорить об этом.
Сейчас колбеки реализованы очень просто. Перед обработкой пришедших данных из глобальной таблицы скрипта вызывается функция колбека, если она есть, и ей передаются параметры. т е все затраты - это вызов функции. Никакой обработки нет. Вы же предлагаете Все переделать ( добавить поток решать вопрос синхронизации нового потока с существующими и т д) Но брокерам этого не надо. А софт QUIK покупают брокеры.
