Nikolay написал: Не уверен, что здесь что-то изменилось. Это просто данные с сервера шли долго (справочники, данные таблиц и т.д.) после установки соединения. На форме уже столько раз об этом спорили, просили разработчиков дать методы определения прихода пактов данных.
Дак вот же оно, в логе - сообщение о коннекте через целую секунду после IsConnected()==1. Что мешает этот признак выставлять после сообщения?
Опять костыли строгать ((
Я давно считаю, что разработчикам этой программы надо также неожиданно периодически заваривать петли на входной двери, как они меняют алгоритмы работы QUIK. Чтобы утром, опаздывая на работу и рискуя ее лишится, они осознали, в каком положении неожиданно для них самих очутились. ИМХО
Дополнение. Заметил, что когда цена доходит до стоп-цены и откатывается назад ордер "исполняется" но сделка по рынку не открывается. Очень странное поведение.
Здравствуйте. Объясните пожалуйста как такое возможно. Размещенный тейк-профит и стоп-лосс сработал. В таблице стоп заявок система указывает, что ордер исполнен. Однако короткая позиция остается висеть и совершенной сделки в системе также не фиксируется. Может быть я не правильно понимаю что с точки зрения системы означает "исполнение" ордера?
Добрый вечер! А нельзя ответить в форуме?... Я думаю всем будет интересно узнать, как объектная модель Квика обрабатывает такие заявки. Вопрос заключается в следующем: Как при входе по рынку сразу выставить две связанных заявки - одна лимитная о рынку (на фиксацию прибыли), другая стоп-заявка тоже по рынку (на фиксацию убытков). Без прохождения цены PRICE.
Вопрос простейший и реализован во многих торговых системах.
Отбой. Это у меня уже крыша поехала бороться с КВИКОМ топорными методами. )))) Может вы все таки подумаете о нормальном встроенном отладчике. Иначе так и будем пользоваться логами и мессаджами а потом бомбить поддержку сообщениями. Вы сами то не устали, админы?...
В дополнение: До 25.11.2022 (до прошлой пятницы) эта строка работала адекватно и не подвергалась изменениям. Проблемы появились с 29.11.2022 сразу после обновления до версии 10.0.1.18. Демо.
Добрый день! Данную ошибку возвращает КВИК!!! На вашем демо счете такая же ситуация. Ниже выдержка кода в комментах указаны возвращаемые значения. Каким волшебным образом плюс меняется на минус, хотелось бы понять)))))))))) Какой выпускник ЕГЭ последнее обновление писал? ))))))))
Скрытый текст
stop_order.Take_related_price = last_candle_day.Open_Current + (last_candle_day.High - last_candle_day.Low); message("TP"..tostring(stop_order.Take_related_price))--127430 = 135600 - (143500 - 135330) ????? КАК?! Это не соответствует введенной формуле message("last_candle_day.Open_Current"..tostring(last_candle_day.Open_Current))--135600 message("last_candle_day.High"..tostring(last_candle_day.High))--143500 message("last_candle_day.Low"..tostring(last_candle_day.Low))--135330
Приветствую всех! В развитие темы пара вопросов: 1) Как получить доступ через LUA к информационным сообщениям QUIK? В частности к информации о наличии обновлений. Вопрос далеко не праздный, т.к. многие поля таблиц иногда отказываются работать если не скачать последние обновления. Отсюда вытекают сложности с автономной работой: ваш робот может не прочитать поле из-за того, что в сети появилось обновление (например поля STATUS и TRADINGSTATUS), со всеми вытекающими. Поддержка везде советует их использовать, но умалчивает о том, что они не работают когда системе необходимо обновление. 2) Как получить доступ к данным котировок начиная с определенного времени или сессии? Другими словами, как получить данные, например, с текущего момента времени без подгрузки истории?
Nikolay написал: Питон тоже самое, только тяжелее, медленнее и со своими проблемами.
Что касается клиент серверного взаимодействия, то вне зависимости от языка, прежде чем проводить операции с данными, полученными с сервера, из принято проверять. Они могут быть не получены, они могут быть некорректными. В вашем примере Вы сразу пытаетесь привести значение к числу, не убедившись, что они есть. Если вернется что-то не то, tonumber вернет nil. А далее Вы с этим будете арифметические действия выполнять.
В данном случае я упростил код. Не буду же я две страницы сюда кидать, заблаговременно зная в чем примерно причина))) Но элементарная проверка типов должна быть на стороне сервера. Программа не должна молчать в случае ввода не типизированных данных.
Решил проблему))))) Нафига я сую строку PRCStr в числовой параметр цены)))) Вот опять вопрос к разработчикам: зачем эти пертурбации с типами на стороне клиента? Ну где еще это есть? Я понимаю что здесь сам дурак, но уже, если честно, запутался. Получая с сервака число, я его, почему-то, должен преобразовать не только в строку, но и целочисленное значение.
Владимир написал: Андрей, Подводные камни Вы можете огрести где угодно - у меня четверть, если не треть всего кода посвящена именно обходу этих камней.
Можете сообщить к чему стоит относится более осторожно? Я лично с подозрением начал относится именно к функциям QLUA. К базовой библиотеке LUA претензий не имею.
Владимир написал: Андрей, Ну, во-первых, приведённая строка НЕ "запрашивает данные с сервера" - она берёт их из Квика. Во-вторых, во "времена ДОС" софт был на порядки более эффективным и менее глючным. В-третьих, за эту долбаную "динамическую типизацию" я бы разработчикам яйца пообрывал. В-четвёртых, заворачивание в tostring помогает в 9 случаях из 10.
Я понимаю, что команда обращается к стеку клиента, но ведь потом она пересылает эти данные на сервер. Другими словами в цепи сервер-клиент-сервер присутствует несогласованность в типе данных. То, что делает клиент с типами данных, не воспринимается сервером. А это уже ПРОБЛЕМА. И проблема говорит о том, что сопровождение софта отсутствует полностью.
И вообще, я не понимаю, зачем надо было выбирать глючный LUA, на котором можно только скрипты для игрушек писать, в ущерб тому же несчастному питону. У которого в тысячу раз больше возможностей и который тоже на С (если так нравится разрабам)... Это при том, что LUA изначально не предназначен для точных вычислений и пр. математики (за исключением арифметики).
В любом случае в программе есть скрытая функциональность не прописанная в документации (преобразование типов). Проверки типов между клиентом и сервером нет - это точно. И нигде это не прописано.
Тут собственно говоря проблема была даже не в том, что запятая пропущена, а в том, что клиент не способен корректно пересылать данные на сервер. обратите внимание на строку ниже: она напрямую запрашивает данные с сервера
А потом просто ретранслирует их обратно через переменную
Код
["PRICE"] = PRCStr
В этом и состоял вопрос: почему клиент не умеет корректно работать с данными сервера. А это уже вопрос к разработчикам. Хотя swerg тоже прав: почему они до сих пор все переводится в строковый вариант)))))) Времена ДОС прям-таки)))))
Андрей написал: Принцип программирования - что запросил то и получил здесь нарушен.
Ничего здесь как раз не нарушено. Запрошена цена - её значение возвращается как double. Все логично.
Цитата
Андрей написал: В таблицах по фьючу РТС явно целочисленные значения приводятся, да и биржа тоже целые транслирует
Это не так. Вы путаете транслируемые и отображаемые значения. Просто QUIK в таблицах при отображении учитывает еще параметр "точность цены", отображая лишь то значение цифр после запятой, которое соответствует указанному параметру.
Цитата
Андрей написал: Я понимаю, что в недоязыке LUA непредусмотрено целочисленных значений
И это не так. Добавление .0 после чисел с типом double появилось в Lua5.3, где есть отдельный целочисленный тип. Но он здесь не применим, т.к. бывают инструменты с дробной ценой. Так что цена универсально возвращается как double, а tostring() приписывает при конвертации .0 в таким аргументам (при целом значении).
Вопрос к разработчикам ровно один и простой: неужели до сих пор нельзя сделать так, чтобы параметр Transaction["PRICE"] можно было задавать числом, а не строкой?!
Господа разработчики, исключите всю ненужную для обывателя информацию из таблиц. 95% информации необходима только для профессионального финансового менеджмента и просто перегружает информативно. Вот в какой таблице, например, найти текущее состояние счета. Под текущим я понимаю мгновенное (с учетом +/- вариационной маржи, комиссии брокера и пр. +/-). Я так понял приходится городить расчеты самому. А для этого надо знать всю объектную структуру программы (что в какую колонку переносится и перезаносится и при каких условиях) - чего нет в наличии. Вот откуда мне узнать за 1 минуту, не читая справки, (что нормально) какое у меня текущее состояние счета при нескольких открытых позициях на срочке и на фондовом без калькулятора?...
Знаю, сталкивался с этим. В переменной PRCStr у тебя строка типа "12345.0" А в транзакцию цену надо передавать строку с учетом шага цены "12345"
Короче, точку с нулем из строки похерь и будет счастье
Код
function cut_zero (str)
local num = tonumber(str)
local zero = string.byte ( "0" , 1 )
local point = string.byte ( "." , 1 )
if ( string.find (num,'%.')) then -- Имеется точка в числе
for n = string.len (num), 1 , - 1 do -- Перебор справа налево
if ( string.byte (num,n) = = point) then return string.sub (num, 1 ,n - 1 ) end
if ( string.byte (num,n)~ = zero) then return string.sub (num, 1 ,n) end
end
end
return num
end
В общем решена проблема. При запросе последней цены и шага цены QUIK зачем-то выводит еще и дробную часть числа, которой в таблице и на бирже и в помине нет и, соответственно, сервер дробные числа также не принимает. В частности по фьючерсу РТС вместо цены 155310 выводит 155310,0. То же самое и с шагом цены вместо 10 выводит 10,0.
Код
tonumber(getParamEx("SPBFUT", "RIH1", "LAST").param_value) -- Выводит десятичное число
tonumber(getParamEx("SPBFUT", "RIH1", "SEC_PRICE_STEP").param_value) -- Выводит десятичное число
Поэтому если работаете с ценами, которые заведомо не имеют дробных частей, то округляйте все запросы к таблицам до целого на всякий случай. Кто знает, где системой еще самостоятельно типы будут преобразовываться.
PS Вопрос к разработчикам, неужели нельзя было включить элементарную проверку типов в функции запроса данных из таблиц? Принцип программирования - что запросил то и получил здесь нарушен. В таблицах по фьючу РТС явно целочисленные значения приводятся, да и биржа тоже целые транслирует, а система QUIK их самостоятельно выводит как десятичные. Я понимаю, что в недоязыке LUA непредусмотрено целочисленных значений, но раз у вас на сервере они фигурируют, то и клиентская сторона должна уметь их ретранслировать.
В дополнение: OnTransReply не выводит своей таблицы, когда цена задана переменной. Прописал цикл сна до получения статуса транзакции, но скрипт выходит из цикла по истечению установленного времени (20с) так и не получив никакого статуса транзакции. Это явно проблема на стороне клиента. Если бы заявки на сервер уходили, ответ бы возвращался. Только вот в чем может быть проблема я не пойму.
Всем привет! Объясните мне, пожалуйста, нижеследующий завих QLUA. Вот так заявка отправляется:
Код
function main()
Transaction={
["TRANS_ID"] = "1005001",
["ACTION"] = "NEW_ORDER",
["CLASSCODE"] = "SPBFUT",
["SECCODE"] = "RIH1",
["OPERATION"] = "B", -- операция ("B" - buy, или "S" - sell)
["TYPE"] = "L", -- L - лимитная
["QUANTITY"] = "1", -- количество
["ACCOUNT"] = "SPBFUT001bm",
["PRICE"] = "155500"
}
sendTransaction(Transaction)
end
А вот так игнорирует заявку:
Код
function main()
local PRCStr = tostring(tonumber(getParamEx("SPBFUT", "RIH1", "LAST").param_value) + 50 * tonumber(getParamEx("SPBFUT", "RIH1", "SEC_PRICE_STEP").param_value))
Transaction={
["TRANS_ID"] = "1005001",
["ACTION"] = "NEW_ORDER",
["CLASSCODE"] = "SPBFUT",
["SECCODE"] = "RIH1",
["OPERATION"] = "B", -- операция ("B" - buy, или "S" - sell)
["TYPE"] = "L", -- L - лимитная
["QUANTITY"] = "1", -- количество
["ACCOUNT"] = "SPBFUT001bm",
["PRICE"] = PRCStr
}
sendTransaction(Transaction)
end
В двух словах: в первом примере цена лимитника задана непосредственно строкой в поле, во втором варианте цена задана переменной. Цена во втором случае высчитывается нормально и выводится в окно оповещений, но заявка не отправляется. Скрипт просто проходит по коду без какой-либо реакции. Ошибок также не выводит. Кто-нибудь знает ЧТО ЭТО ЗА БРЕД? Терминал обновлял. Демо версия 8.11.0.66. Счет зарегистрирован у ARQA. Перезагружался. Монитор протирал.))) Мышку гладил.))) Мастдай не переустанавливал. Не предлагать.
Это я видел. Dll это не исполняемый файл интерпретатора. Скорее всего ЛУА зашит в код. А вот что касается версий используемых библиотек, то у меня например 2 dll: 5,1 и 5,3. Какую из них и когда он подключает и, следовательно, могут ли этим вызываться ошибки и какие - это тайна за семью печатями.
В дополнение к вышесказанному хочу заметить, что для софтины, которая предназначена для манипулирования финансовыми средствами в немалых объемах, отсутствие собственного отладчика это полная лажа. Такая программа должна комплектоваться или комплектом ЯП-редактор-отладчик, либо полностью документированным открытым ВЫСОКОПРОИЗВОДИТЕЛЬНЫМ API. Создается впечатление, что у вас либо нет заинтересованности в поддержке и сопровождении этого проекта, либо вы просто его уже не вывозите.
Эту тему тоже подниму! 4 года прошло. Quik переведен на 64 разряда. Разрабы, а где нормальный человеческий отладчик с редактором LUA?! Несчастный МТ вас и то обошел по всем параметрам. Ваша платформа скоро будет использоваться просто как шлюз, потому как вся остальная ее начинка либо глючная, либо просто брошенная на половине разработки. Вам самим не скучно так бездарно тратить время на разработки, которые в принципе не работоспособны без костылей? Блин, вы даже API нормальный сделать не можете. До сих пор сидите на тормознутом DDE и ODBC. Уже никто их не использует. Ну вы хотя бы погуглите и посмотрите способы обмена информацией в среде Винды, ведь их целая куча и они довольно высокопроизводительные. Почему пользователи в 21 веке пользуются костылями времен мастдая 95?! Зачем все эти ваши нововведения, если реализовать их без костылей не получается?! Давайте в следующем обновлении QUIK еще модель COM воскресим!!! Где нормальный встроенный отладчик для LUA в QUIK??? Еще раз задаю вопрос.
Подниму тему, потому что ответа в ней так и не прозвучало!!! В который раз! Парни! Поддержка! У вас человек спрашивал ПО КАКОМУ АДРЕСУ НАХОДИТСЯ ИСПОЛНЯЕМЫЙ ФАЙЛ ИНТРЕПРЕТАТОРА LUA ИЛИ ПО КРАЙТЕЙ МЕРЕ ЕГО ТЕКУЩАЯ ВЕРСИЯ!!!!! Или по другому: куда QUIK устанавливает свой интерпретатор LUA, которым он пользуется! МЕНЯ ЭТО ТОЖЕ ИНТЕРЕСУЕТ. Объясняю для тех кто в танке: при использовании сторонних IDE требуется указывать локальный адрес интерпретатора. Так вместо того, чтобы самому методом тыка подбирать соответствующую версию и потом еще следить за их соответствием между QUIK и IDE, можно же просто в IDE указать путь к интерпретатору QUIK и не париться потом с его сопровождением, обновлениями и синхронизацией версий!!!! То есть, зная путь, можно сделать так, чтобы ваша IDE автоматически использовала тот же интерпретатор что и QUIK, со всеми его обновлениями и пр. Если же вы все же на кой-то ляд зашили его в код, тогда где искать номер его сборки?!