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

Благодарю

При обновлении версии 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-й? Очевидно, что это не код самого скрипта, который не имеет доступа к адресному пространству ни процесса интерпретатора, ни терминала.

Ну я пишу, что есть по факту. Скрипт молотит без этих строк и не рушит терминал. С ними крэш воспроизводится 100%. Из чего следует, что работа с таблицами из Lua сломана в 9-й версии.Действительно, не обратил внимания! Немного сбило с толку, что там попросили воспроизвести в 9.3.3.3  

Похожая проблема уже была озвучена ранее, но тогда от нее отмахнулись, т.к. она была в версии 9.3.1.11:
Critical error ACCESS_VIOLATION in script...

Следует отметить, что у меня тоже иногда сообщение об ошибке выглядит как на моем скриншоте, а иногда как "Critical error ACCESS VIOLATION..."

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

При чем тут RGB? RTFM

И спасибо за ваше ценное мнение о длине идентификаторов и ошибках. Однако я сразу отметил, что код стабильно работал в 8-х версиях терминала. Ошибок в нем действительно нет.

Добрый день!

Скрипт, который работал без проблем в версии 8.11, перестал работать в версии 9.3.1.11. Обновление до 9.3.3.3 проблему не решило (см. скриншот).

Сторонние библиотеки не используются вообще. Ни на Lua, ни DLL, т.е. проблема в самом терминале без вариантов. Крэш происходит при запуске скрипта как версией интерпретатора 5.3, так и 5.4

Удалось локализовать проблему в следующих строках:

Эти строки выполняются в цикле для каждой строки таблицы по мере обновления данных в ней. Крэш устраняется, если сделать следующие изменения:

Идентификаторы колонок определены следующим образом:

Переменная mktForceFgColor может принимать одно из трех значений: QTABLE_DEFAULT_COLOR, RGB( 0, 200, 0 ), RGB( 200, 0, 0 )

Проблема серьезная, требует оперативного решения!

Zoya Skvorcova, здравствуйте.

Было бы чудесно, спасибо!

Спасибо за внимание к проблеме!

С DDE ситуация еще более-менее понятна, но почему при копировании содержимого пользовательской таблицы в буфер обмена по CTRL+C, туда попадает не ее содержимое, а нули?

Добрый день, Станислав

Спасибо, что не оставили эту проблему без внимания! Буду ждать обновления версии терминала у брокера.

С уважением,
Роман

Анастасия, добрый день!

Спасибо за оперативный ответ. Вы меня выручили и вы правы: я не досмотрел - поле "Базовый актив" действительно отсутствовало в списке получаемых параметров. Это наверное логично, потому что когда я последний раз выполнял операцию "Установить настройки по открытым таблицам", его не было ни в одной таблице. Просто меня сбило с толку, что поле "Класс базового актива" тем не менее было доступно, хотя его тоже не было нигде при сбросе настроек по открытым на тот момент таблицам.

С уважением,
Роман

Понял вас. Спасибо!

Прилагаю скриншоты:

Добрый день!

Сегодня обнаружил, что теперь из таблицы текущих параметров невозможно получить базовый актив опциона! Не уверен с какой версии это началось, но в 7.14 этот параметр там был. Более того, он по прежнему фигурирует в документации (см. приложение с описанием параметров таблицы).

В текущей версии, предлагаемой брокером - 7.16.3.14 - в таблице текущих параметров есть поле "Класс баз.актива", но "Баз.актив" отсутствует.

Прошу рассмотреть возможность устранения этого недочета.

С уважением,
Роман

Добрый день!

На данный момент (после некоторого числа обновлений) в версии 7.16.3.14 данная проблема так и не была исправлена!

Добрый день,

Отлично. Еще раз спасибо за оперативность!

С уважением,
Роман

Благодарю за оперативный ответ!

Добрый день,

После перехода брокера на версию Quik 7.16.1.36 обнаружил, что есть серьезные проблемы при построении графика волатильности опционов (правый клик по волатильности в Доске Опционов и далее "График [Волатильность]").

Графически данные отображаются нормально, но текущее значение, значения пользовательских уровней, а также данные во всплывающей при наведении мыши на график подсказке, отображаются как целые числа!

Существует ли какой-нибудь способ увеличить точность вручную хотя бы до двух знаков?

С уважением,
Роман