При обновлении версии 10.1.3.8 на последнюю из серии 10.2.х (к сожалению полную версию не записал, т.к. пришлось мгновенно откатить обновление из-за описываемой проблемы), обнаружил, что getParamEx() возвращает некорректные значения параметра "LOTSIZE" по фьючерсам на акции.
К примеру для PLZL возвращается param_image=10, param_value=1.0
В версии 10.1.3.8 возвращается param_image=10, param_value=10.0, как и должно быть.
Это критическая ошибка, требующая скорейшего исправления.
Сегодня впервые столкнулся с этой проблемой. Терминал версии 9.3.3.3. Проблема выглядит серьезной, поэтому хотелось бы привлечь внимание разработчиков терминала.
Согласно документации терминала, функция sendTransaction() возвращает сообщение с текстом ошибки, если транзакция не была отправлена на сервер, иначе транзакция считается отправленной. Это создает необходимые условия для построения надежной логики обработки результатов транзакций:
1. Вызываем sendTransaction() 2. Если возникла ошибка, реагируем (например, посылаем транзакцию повторно или отказываемся от нее) 3. Если ошибки не возникло, от ждем срабатывания OnTransReply() с соответствующим значением поля trans_id, чтобы получить состояние отправленной транзакции в поле status 4. Если значение status сигнализирует об ошибке, реагируем (например, посылаем транзакцию повторно или отказываемся от нее) 5. Иначе транзакция успешно отправлена.
Скрипт, использующий эту логику, сегодня впервые дважды завис на этапе ожидания OnTransReply(), т.к. событие терминалом просто не было сгенерировано. При этом предшествующий вызов sendTransaction() прошел без ошибок и вернул пустую строку.
В обоих случаях, речь шла о транзакции для перемещения ордера (MOVE_ORDERS). Такие транзакции периодически генерируют ошибки, т.к. передвигаемый ордер может быть исполнен в момент перемещения. Однако эти ошибки возвращаются через OnTransReply() со следующими сообщениями:
- "Не найдена активная заявка для перестановки" - "Ошибка перестановки заявок. [GW][50] "Не найдена заявка для перестановки."
Но в обоих проблемных случаях сегодня, в окне сообщений терминала я видел сообщение вида: "Вы не можете заменить заявку 1892947247341804353. Повторите попытку позже."
Таким образом, возникает ситуация, когда код не получает никакой возможности обработать ошибку (sendTransaction() выполняется успешно, OnTransReply() не приходит).
Kalmar, код выполняется интерпретатором Lua и не использует DLL. Что в нем может вызывать AV в 9-й версии терминала, что не вызывало AV в 8-й? Очевидно, что это не код самого скрипта, который не имеет доступа к адресному пространству ни процесса интерпретатора, ни терминала.
Цитата
Kalmar написал: Ну вот просто: -чем две закоментаренные строки отличаются от двух предыдущих?И нет никакой гарантии, что если убрать все четыре SetColor-а то падать перестанет. Просто будет падать в другом месте, при других условиях.
Ну я пишу, что есть по факту. Скрипт молотит без этих строк и не рушит терминал. С ними крэш воспроизводится 100%. Из чего следует, что работа с таблицами из Lua сломана в 9-й версии.
Цитата
Kalmar написал: Хочу заметить, что тут картина наоборот. на 9.2 работает, а на 8.11 ломается.
Действительно, не обратил внимания! Немного сбило с толку, что там попросили воспроизвести в 9.3.3.3
Владимир, серьезность проблемы заключается в критической нестабильности последних версий терминала при выполнении скриптов на Lua, информация о которой поможет разработчикам продукта. Пока что мне удалось изолировать один из триггеров, но нет никаких гарантий, что все ограничивается лишь вызовами SetColor(). Я рад, что для вас это всего лишь раскраска, но вам явно не приходило в голову, что она появилась в коде не просто так. Иначе бы ее не было изначально.
При чем тут RGB? RTFM
И спасибо за ваше ценное мнение о длине идентификаторов и ошибках. Однако я сразу отметил, что код стабильно работал в 8-х версиях терминала. Ошибок в нем действительно нет.
Скрипт, который работал без проблем в версии 8.11, перестал работать в версии 9.3.1.11. Обновление до 9.3.3.3 проблему не решило (см. скриншот).
Сторонние библиотеки не используются вообще. Ни на Lua, ни DLL, т.е. проблема в самом терминале без вариантов. Крэш происходит при запуске скрипта как версией интерпретатора 5.3, так и 5.4
Удалось локализовать проблему в следующих строках:
С DDE ситуация еще более-менее понятна, но почему при копировании содержимого пользовательской таблицы в буфер обмена по CTRL+C, туда попадает не ее содержимое, а нули?
Спасибо за оперативный ответ. Вы меня выручили и вы правы: я не досмотрел - поле "Базовый актив" действительно отсутствовало в списке получаемых параметров. Это наверное логично, потому что когда я последний раз выполнял операцию "Установить настройки по открытым таблицам", его не было ни в одной таблице. Просто меня сбило с толку, что поле "Класс базового актива" тем не менее было доступно, хотя его тоже не было нигде при сбросе настроек по открытым на тот момент таблицам.
Сегодня обнаружил, что теперь из таблицы текущих параметров невозможно получить базовый актив опциона! Не уверен с какой версии это началось, но в 7.14 этот параметр там был. Более того, он по прежнему фигурирует в документации (см. приложение с описанием параметров таблицы).
В текущей версии, предлагаемой брокером - 7.16.3.14 - в таблице текущих параметров есть поле "Класс баз.актива", но "Баз.актив" отсутствует.
Прошу рассмотреть возможность устранения этого недочета.
После перехода брокера на версию Quik 7.16.1.36 обнаружил, что есть серьезные проблемы при построении графика волатильности опционов (правый клик по волатильности в Доске Опционов и далее "График [Волатильность]").
Графически данные отображаются нормально, но текущее значение, значения пользовательских уровней, а также данные во всплывающей при наведении мыши на график подсказке, отображаются как целые числа!
Существует ли какой-нибудь способ увеличить точность вручную хотя бы до двух знаков?