Я видел эту ссылку, но мне не нужно снимать все заявки, мне нужно снять именно конкретную заявку и ловить по ней события. И благодаря помощи участников форума проблему мне удалось решить.
QuantPro Platform
Не снимаются заявки в секции FORTS
Пользователь
Сообщений: Регистрация: 29.06.2015
13.06.2023 12:30:47
Знаете, а Вы, скорее всего, правы. Я делаю преобразование с помощью lua_tonumber, а оказывается, что начиная с версии 5.3 lua_Integer - это 64-битный целый тип и можно использовать lua_tointeger. Большое спасибо за помощь, коллективный разум - это сила )
QuantPro Platform
Не снимаются заявки в секции FORTS
Пользователь
Сообщений: Регистрация: 29.06.2015
13.06.2023 12:00:28
У меня C++, преобразование идет напрямую из Lua Number в uint64_t, а потом уже пишется в лог. По всей видимости, дело действительно в ошибках преобразования из double в uint64_t, судя по Если это так, то возникает резонный вопрос к разработчикам - собираются ли они это исправлять и когда. Учитывая, что Lua не имеет целочисленных типов, а биржа транслирует значения за пределами значений double, тут видится два варианта: или разбивать число на две части и передавать в двух полях, или сделать просто строковое поле.
QuantPro Platform
Не снимаются заявки в секции FORTS
Пользователь
Сообщений: Регистрация: 29.06.2015
13.06.2023 10:32:38
Цитата
paluke написал: Проверил у себя. На quik 10.1 order_num в OnTransReply имеет тип integer, и номер там без искажений, совпадает с тем что в result_msg. Автор, а брокер у вас какой?
БКС. Проверял на разных версиях, везде одно и то же.
QuantPro Platform
Не снимаются заявки в секции FORTS
Пользователь
Сообщений: Регистрация: 29.06.2015
11.06.2023 22:00:16
Цитата
nikolz написал: ваш пример не корректный в нем есть неявный формат печати. Вы уверены что он 64 битный?
Если вопрос ко мне, то да, все значения 64-битные. К тому же, если бы имел место некорректный формат печати, то он был бы некорректен во всех случаях. Но это, как Вы можете видеть, не так.
Спасибо, но это не тот случай. Попытки отправить по нескольку раз не увенчиваются успехом. А вот при подстановке значения из result_msg заявки прекрасно снимаются, собственно, что и следовало ожидать, так как они всегда совпадают со сначением из таблицы заявок. Пока мне пришлось закостылить регулярку и вытаскивать этот номер из result_msg, но согласитесь, что этот способ так себе решение. Все же хотелось услышать мнение кого-нибудь из разработчиков по данному вопросу.
QuantPro Platform
Не снимаются заявки в секции FORTS
Пользователь
Сообщений: Регистрация: 29.06.2015
11.06.2023 16:38:51
Цитата
nikolz написал: В OnTransReply может и не быть order_num, так как это ответ сервера брокера на обработку транзакции. Первый раз этот ответ приходит раньше, чем ответ с сервера биржи.
Действительно, Ваш ответ можно было бы принять, но есть нюанс. В поле result_msg номер заявки присутствует, и он всегда верный. Так что проблема явно на стороне квика, уж не знаю там, сервера или клиента. В моем первом сообщении Вы можете увидеть оба случая, когда номера совпадают и когда нет.
QuantPro Platform
Не снимаются заявки в секции FORTS
Пользователь
Сообщений: Регистрация: 29.06.2015
09.06.2023 19:57:04
В колбеке OnOrder тот же самый order_num, что и в OnTransReply, поэтому его для снятия заявки использовать не получится. А вот брать из таблицы действительно можно, только выглядит это очень уж коряво. И вопрос остается: почему в OnTransReply order_num не совпадает с тем, который в таблице заявок. И еще более удивительно, что иногда они все-таки совпадают. А вот для фондовой секции они совпадают всегда и я спокойно могу использовать order_num из данных, приходящих в OnTransReply.
QuantPro Platform
Не снимаются заявки в секции FORTS
Пользователь
Сообщений: Регистрация: 29.06.2015
07.06.2023 17:42:22
Добрый день.
Обнаружил странное поведение при выставлении заявок на FORTS. Поле order_num, приходящее в колбеке OnTransReply, часто не совпадает со значением в таблице заявок квика, из-за этого не удается программно снять заявку. Тем не менее, бывают редкие случаи, когда эти значения совпадают, и тогда заявки снимаются. При этом обнаружил, что в поле result_msg номер заявки всегда верный. Вот реальные примеры совпадающих номеров и несовпадающих:
SG написал: У вас переполнение типа int. Номера заявок и сделок - это 64-битные целые числа.
SG прав...
ошибка в строчке:
Код
int N = lua_tonumber(L, - 1 );
добавлю только, что судя по определению:
Код
typedef double lua_Number;
lua_Number lua_tonumber (lua_State * L, int index);
произошло преобразование значения типа double превышающего максимально возможное значение типа int, в результате чего было получено значение INT_MIN из <climits> (limits.h)
Код
# define INT_MIN ( - 2147483647 - 1 ) / * minimum (signed) int value * /
Тем не менее, должен заметить, что проблема до конца не решается. Судя по официальной информации, диапазон поддерживаемых целых чисел ограничен 100 000 000 000 000.
QuantPro Platform
Исключение при вызове функции getSecurityInfo()
Пользователь
Сообщений: Регистрация: 29.06.2015
29.06.2015 20:46:27
Забыл упомянуть, что исключение возникает при вызове lua_next().
QuantPro Platform
Исключение при вызове функции getSecurityInfo()
Пользователь
Сообщений: Регистрация: 29.06.2015
29.06.2015 20:39:05
Добрый день.
К сожалению, не нашел, где у вас баг-трекер, поэтому пишу сюда.
Я разрабатываю коннектор для алгоритмической торговли через интерфейс C++ - Lua. В lua скрипте только лишь загружается библиотека, весь остальной функционал реализован на C++. Выяснилось, что в момент вызова функции getSecurityInfo() в случае, если у терминала нет информации по запрашиваемой бумаге, он возвращает данные по бумаге, по которой у него был в последный раз удачный вызов. Если же до этого не было вызовов данной функции, терминал прекращает работу скрипта с сообщении о необработанном исключении. Могу предположить, что в этот момент в самом терминале происходит чтение неинициализированной памяти или нечто в этом роде.