Алексей (Автор тем)

Quik 7.19.3.1
В процессе завершения работы (после получения OnStop) скрипт вызывает ds:Close() для всех открытых с помощью CreateDataSource в процессе своей работы источников данных свечек.
В руководстве Qlua сказано, что при успешном завершении вызова должно возвращаться true. Однако приходит false.
Может быть после прихода OnStop уже нет смысла беспокоится о закрытии ds, т.к. Quik уже сам все закрыл?

Допустим запущено несколько скриптов, установивших обработчики через SetUpdateCallback от CreateDataSource для одного и того же инструмента. Одновременно с этим в системе работают несколько пользовательских индикаторов для того же инструмента.
1. Существует ли определенный порядок вызовов функций обратного вызова скриптов и индикаторов при поступлении с сервера информации о совершенной на бирже с инструментом сделке, т.е., например, сначала вызываются все OnCalculate для пользовательских индикаторов и лишь за тем все Callback-и в скриптах (или наоборот), либо порядок вызовов Callback-ов и OnCalculate - произвольный?
2. Если определенный порядок существует, то каков он, и каково в нем место для OnAllTrade?

Пользователи Telegram-Bot!

Поделитесь соображениями, как обойти предстоящую блокировку.

Использую lua-telegram-bot API от @cosmonawt.
Но он, в свою очередь, опирается на "LuaSec 0.6 - Copyright © 2009-2016 PUC-Rio" (для поддержки https SSL), который, похоже, не поддерживает работу через proxy. Либо я не понимаю, как прописать настройки для работы через proxy.

Подскажите, как в новых условиях поддерживать работу Telegram-Bot?

Сегодня 22.02.2018 в 11:59:56 на FORTS lua-скриптом была выставлена заявка 29545190638 с заполненным полем CLIENT_CODE.
В ответ пришел OnTransReply с пустым полем brokerref = "".
Последующие OnOrder и OnTrade содержали правильно заполненное поле brokerref.
Проблема в том, что мой скрипт фильтрует поток по brokerref. В итоге его модуль обработки содержимого OnTransReply, OnOrder и OnTrade не получил OnTransReply.

Не заполненное поле brokerref в OnTransReply - это единичный баг сервера брокера или допустимое событие в протоколе обмена сервера с клиентским местом?

Подключен к Сбербанку без доступа к валютному рынку.
Однако Брокер транслирует в классе FORTS: Кросс-курсы инструмент SPBUSR (я так понимаю, что это индикативный курс Мосбиржи, рассчитываемый по USDRUB_TOM).
Для этого инструмента не транслируется параметр Price (Цена), но есть параметр Курс.
Можно ли как-то вывести график изменения этого параметра?

Сценарий, воспроизводящий ошибку:
1. Растянуть вертикальную ось диаграммы до появления вертикального scrollbara.
2. Развернуть окно диаграммы на весь экран
3. Восстановить размер окна диаграммы (свернуть в окно).
В результате scrollbar не отрисовывается, на его месте остается неперерисованный кусок, заполненный участком изображения, оставшегося от развернутого окна.
Scrollbar восстанавливается после наведения на него мышкой (либо после любого другого события, приводящего к получению контролом win сообщения).
quik 7.14.1.7
win vista

Столкнулся с таким вот казусом:
Скрипт запускается со стартом Quikа (7.14.1.7), т.е. еще до соединения с сервером.
Однако ничего существенного не делает и ждет OnConnected.
Получив подтверждение связи с сервером, переходит в полноценный режим и начинает, кроме прочего, отрабатывать колбеки OnOrder, OnTrade и т.п., которые вызывает Quik по мере стартового заполнения своих соответствующих таблиц записями о событиях, которые были до включения Quika (мои вчерашние сделки и т.п.)
И тут приходит OnCleanUp...
Ничего, вроде бы, страшного нет, скрипт тоже не слепой, и при необходимости может рестартовать и все заново корректно отработать уже с новой актуальной информацией.

Но вот, что вдруг вылетело:
Скрипт умер внутри колбэка OnTransReply (это был ответ на транзакцию текущего служебного обмена информацией терминала и сервера брокера) на инструкции:
f = tab.brokerref and tab.brokerref:find(TEname)
bad argument #1 to 'find' (string expected, got nil)

где tab - таблица, переданная Quikом в OnTransReply.
Весело получается: когда интерпретатор успешно нашел адрес функции string.find, tab.brokerref еще был строкой, а когда уже стал формировать стек вызова функции find, то tab.brokerref сдох до nil !

Я понимаю, что вероятность второй такой поимки покемона крайне мала, но все же не нулевая.

Уважаемая техподдержка QUIK!
Прошу сделать так, чтобы QUIK, перед очисткой своих внутренних таблиц по OnCleanUp, убедился, что вышел из всех колбеков lua скриптов, и вызывал OnCleanUp скриптов только после завершения своей полной очистки.
Или дайте иное объяснение произошедшего.

Сегодня "поймал" неприятную историю: заявка, отправленная на последних секундах торгов, не ушла на биржу.
Есть основания полагать, что это ошибка СЕРВЕРА QUIK.

Детали: Скрипт отправил заявку Forts в 18:44:45 по часам моего компьютера.
Могу со 100% гарантией утверждать, что время моего компьютера отличается от времени биржи не более, чем на 0.5 секунды. (исходя из логов OnTrade, OnOrder и т.п.)
Часы сервера брокера сегодня спешили на 32 секунды, т.е. по часам брокера заявка поступила к нему в 18:45:17
В результате, заявка не ушла на биржу, пришел OnTransReply датированный 18:45:17.789  с формулировкой <Ошибка создания заявки. [GW][3] "Сейчас эта сессия не идет.".>,
Однако, исходя из логов трансляция обезличенных сделок прекрасно продолжалась еще 15 секунд, информация о последней обезличенной сделке поступила в 18:45:00.328 по часам моего компьютера (еще одно подтверждение хорошей синхронизации моих часов с биржевыми).

Правильно ли я понимаю, что сервер брокера решает, когда заканчивается торговая сессия по своим часам, а не по реальному состоянию торгов на бирже?

Прошу техподдержку Quik прокомментировать произошедшее.

Подскажите, пожалуйста, должна ли функция обратного вызова для SearchItems возвращать строго true - false, или можно возвращать (как это обычно принято в lua) для отрицательного результата возвращать false или nil, а для положительного результата - любое другое значение.

Транзакция на снятие заявки требует указания не только номера заявки, но и кодов класса и инструмента.
Отсюда возникает вопрос: насколько уникален в течение торговой сессии номер заявки?
Он действительно уникален или уникален в пределах класса инструментов (class_code + order_num) или уникальной является лишь комбинация class_code + sec_code + order_num?

Подскажите, пожалуйста, сколько и с какими flags придут колбеки OnOrder() в случае возникновения ошибок на этапе исполнения выставленной заявки (получен OnOrder с непустым reject_reason)?
Точнее, скорее интересует как можно понять, что поступил, наконец, последний вызов OnOrder()?

Так же прошу подсказать, как можно определить, что пришел наконец последний OnTrade() по конкретной сделке?
Сейчас, как правило, приходит 3 идентичных вызова OnTrade() для каждой сделки.

Проясните для меня, пожалуйста, следующую ситуацию.

Обнаружил, что терминал сам отправляет на сервер транзакции с заполненным trans_id, и соответственно они попадают в Таблицу транзакций, а также провоцируют вызов OnTransReply().
Первые 2 уходят в момент соединения с сервером, последующие, ровно раз в 120 секунд:
1. trans_id = 10, result_msg = Запрос описания таблицы алго-заявок успешно выполнен.
2. trans_id = 14, result_msg = Initialization user successful.
3. trans_id = 11, result_msg = Транзакция успешно выполнена.
4. trans_id = 12, result_msg = Транзакция успешно выполнена. и т.д. каждые 120 секунд

Это нормальная работа терминала? Quik 7.7.0.89
Запущенных скриптов нет, ни lua, ни qpile. Trans2Quik не пользуюсь, обработка внешних транзакций отключена. Файлов *.tri нет, импорт транзакций из файла отключен.
Откуда они берутся?

Помогите, пожалуйста, разобраться со следующими полями таблицы trans_reply, передаваемой в callback OnTransReply(TABLE trans_reply).

1. server_trans_id NUMBER Идентификатор транзакции на сервере.
        Он отличается от trans_id, указанного при вызове sendTransaction()? Если да, то для чего он нужен?
        trans_id, который мы получаем в таблицах, передаваемых в OnTrade и OnOrder, соответствует trans_id переданному в sendTransaction, или он соответствует server_trans_id?

2. balance NUMBER Остаток.
        О каком остатке может идти речь на этапе регистрации заявки?
        Или уже после регистрации заявки OnTransReply все еще продолжает вызываться также как и OnOrder по мере частичного исполнения заявки?

3. client_code STRING Код клиента, brokerref STRING Поручение.
       При выставлении заявки вручную, можно предположить, что могло бы попасть в client_code, а что в brokerref. Но в этом случае OnTransReply не вызывается.
       При отправке транзакции вызовом sendTransaction(), можно задать только CLIENT_CODE. Это значение, насколько я понимаю, попадает в brokerref таблицы trans_reply (а также в brokerref таблиц заявок и сделок в OnOrder и OnTrade). Так что же тогда мы получаем в client_code при вызове OnTransReply? Действительно Код клиента или там дублируется brokerref?

4. exchange_code STRING Биржевой номер заявки.
       Это опечатка во всех руководствах? То есть нужно читать: Код биржи в торговой системе, или это еще какой-то номер заявки, отличный от order_num?

Заранее благодарен за разъяснения.

Подскажите, пожалуйста, как будет исполнена рыночная заявка FORTS, если в качестве цены указать не максимально (минимально) возможную цену для инструмента, а цену, отстоящую от лучшего предложения только на несколько шагов цены (разумеется, в правильном направлении), при условии, что количество предлагаемых лотов в биржевом стакане в этом диапазоне цен будет меньше, чем указано в заявке?

Обратил внимание, что у меня время сервера, отображаемое в нижней строке состояния QUIK (=getInfoParam("SERVERTIME")), как правило, более, чем на 3 секунды отстает от эталонных часов.
Брокер Сбербанк. Каких-либо запредельных значений "Задержек данных при обмене с сервером" (=getInfoParam("LASTPINGDURATION")) не наблюдаю (не более 0.2 с, обычно на порядок меньше: 0.02-0.04).
Что это значит?
Информация о сделках на бирже поступает на мой терминал с запаздыванием более, чем на 3 секунды?
Или это просто кривые часы на сервере брокера? Но тогда индикаторы по любому отстают от событий на бирже более чем на эти 3 секунды, т.к. информация о свечках формируется сервером брокера по его часам.

Использую QUIK 7.2.2.3, который предоставляет Сбербанк.

Возможно, я лишь для себя открыл Америку..

Обнаружилось, что QUIK ищет скрипты индикаторов не только в самой папке LuaIndicators, но и во всех её подпапках.
Хотелось бы, чтобы на это было обращено внимание начинающих пользователей в руководстве по эксплуатации QLua, что бы предостеречь их от пустой траты времени.

Сейчас в руководстве об этой особенности не упоминатеся:
Кроме того, QUIK занимается подобным сканированием ещё и на старте, причем, столько раз, сколько пользовательских индикаторов должно быть выведено в окнах графиков.

Я в подпапках хранил всякие "эксперименты", естественно, иногда недописанные.

Когда я сегодня утром включил QUIK, а он напрочь отказался запускаться, я только через полчаса вспомнил, что накануне вечером бросил на полдороги работу над скриптом, в Body которого был цикл, который без правильной инициализации становился бесконечным.


Надо иметь в виду, что когдаон, по сути,запускает на исполнение все файлы с расширением lua и в самой папке LuaIndicators, и во всех ее подпапках. И, если в найденных скриптах в Body присутствуют тяжелые вычисления, то это заметно подвешивает терминал.

Где-то я встречал на просторах форума жалобы пользователей на тормоза quika при вызове контекстного меню в окнах графиков, а также на старте терминала, но не видел от технической поддержки внятных комментариев по этому поводу.

Похоже не я один использую подпапки LuaIndicators для хранения экспериментального мусора...
Точнее, до сего дня использовал...

В 10:20 запустил скрипт, анализирующий свечки SiH7 на минутном интервале.
CreateDataSource предоставил историю в 6021 свечек (свеча 10:00 имела номер 6001), callback стал вызываться для текущих свечек, начиная с 6021 свечки.
Через несколько минут скрипт был остановлен, а, затем, в 10:42 запущен вновь.
И что мы видим?  
CreateDataSource предоставил историю в 3043 свечек (свеча 10:00 имела номер 3001), callback стал вызываться для текущих свечек, начиная с 3043 свечки.

1. Если бы скрипт не останавливался, произошла бы перенумерация свечек?
Если бы произошла, то callback просто выдал бы следующую свечу в новой нумерации? Например, если перенумерация произошла бы ровно в 10:30: была свеча 6031, а следом за ней, вдруг пришла бы свеча 3031?
Или же callback бы в этом случае был бы вызван для всей истории в новой нумерации, начиная с 1-й свечи.

2. Если терминал запустить круглосуточно и скрипт вообще не останавливать, то как себя ведет callback от CreateDataSource при смене сессии?
Он в конце торгов выдаст свечу 23:49 за номером 3810, а потом в 10:00 выдаст свечу 3001 (или 6810 ->6001 соответственно)?
Или же callback в случае перенумерации будет вызван для всех свечей в новой нумерации, начиная с 1?

Подскажите, пожалуйста.

Допустим скрипт внутри себя рассчитывает множество индикаторов на основании свечек одного конкретного инструмента с одним и тем же тайм-фреймом (речь идет о внутренних "индикаторах" для нужд робота, т.е. запросы делаются в рамках работы одного скрипта).

1. Будет ли нагружать систему многократный вызов CreateDataSource (каждый для своего экземпляра класса, обсчитывающего конкретный индикатор) в плане расхода памяти, или же QUIK кеширует идентичные запросы CreateDataSource, возвращая каждый раз ссылку на одну и ту же таблицу свечек?

2. Тоже в плане нагрузки на трафик: Если QUIK получил множество запросов от CreateDataSource с одним и тем же инструментом и одним и тем же тайм-фреймом, он организует для каждого запроса свой идентичный поток свечек с сервера или ограничится одним потоком?

Подскажите, пожалуйста, как можно использовать CreateDataSource, если передавать в нее необязательный Param?

Какие значения может принимать Param?
Если это наименование параметра Таблицы обезличенных (всех) сделок (ТВС), то будет ли это работать, если задать интервал, отличный от тикового?
Хотя в руководстве сказано, что "Если параметр не задан, то заказываются данные на основании Таблицы обезличенных сделок, если задан – данные по этому параметру"
Получается, что если параметр задан, то данные берутся не из таблицы обезличенных сделок, а, значит, с использованием Param нельзя заказать данные из ТВС.
Тогда откуда можно заказать данные с использованием Param? Из Таблицы текущих торгов? Из стакана?

Примеры из руководства:
ds3 = CreateDataSource("SPBFUT", "RIU3", INTERVAL_M1, "bid")  
ds1 = CreateDataSource("SPBFUT", "RIU3", INTERVAL_M1, "last")

bid и last - это поля таблицы текущих торгов? Где можно увидеть исчерпывающий перечень всех полей из этой таблицы? Я в руководстве qlua не нашел.

Как из обработчика, установленного через SetUpdateCallback, получить значение заказанного Param? ds:[Param](index) или ds:[Param][index]?

Уважаемые коллеги!
Подскажите, пожалуйста, начинающему "писателю".

Что такого особенного надо сделать при наступлении события OnClose, чего уже поздно будет делать при обработке OnStop, которое, я так понимаю, неминуемо наступит сразу после OnClose?
Другими словами для чего нам нужно событие OnClose, кроме как для получения просто "интересной", но, как мне кажется, бесполезной информации, о том, что скрипт прекращает работу не в результате нажатия кнопки "Остановить", а в результате закрытия терминала?
Или подскажите, пожалуйста, идеи, сценарии, когда скрипт должен был бы по разному прекращать свою работу, в зависимости от причины его остановки.

Добрый день!

При написании своего специфического индикатора иногда возникает необходимость делать некоторые начальные настройки в его работе в зависимости от того, для какого инструмента он строится.
Однако, из Init() вызывать getDataSourceInfo() бессмысленно (мы получим информацию только о тайм-фрейме). Перезапускать рабочее место Quik после добавления индикатора на график, как указано в "Руководстве пользователя QLua" как-то не хочется.
(На самом, деле нужно как-то заставить Quik повторно вызвать Init() индикатора, что можно, впрочем, сделать и без перезапуска рабочего места, а просто некоторыми манипуляциями с самим окном графика. Но это тоже не выход).

Что посоветуете?

Первое, что мне самому приходит в голову, это выполнить нужные настройки при первом же вызове OnCalculate().
getDataSourceInfo() здесь уже будет работать корректно, т.к. к этому моменту Quik уже "привязал" новый индикатор к источнику данных.
Но это тоже не самый красивый ход: каждый раз проверять индекс, отлавливая именно первую свечку, чтобы не заниматься настройками вообще при каждом вызове OnCalculate() и т.д.

Вопрос к разработчикам: я так понимаю, что, при добавлении Lua индикатора на график, Init() вызывается до "подключения" к источнику данных. А что мешает его вызвать после? Так ли важно знать количество линий на индикаторе до "подключения" к источнику данных? Если обеспечить корректную работу getDataSourceInfo() при первом после добавления индикатора на график вызове Init() все же нельзя, то хотел бы попросить разработчиков добавить дополнительный СallBack, типа Init2() после "подключения" к источнику данных, но до первого вызова OnCalculate(). Можно, например, это делать не для каждого индикатора, а только если Init() вернет "соответствующую просьбу".

Добрый день!

При включении фильтра по времени некоторые Lua индикаторы отображаются неверно (quik 7.2.2.3). Приходится зайти в редактирование настроек любого Lua индикатора и, затем, закрыть его, чтобы индикаторы стали работать корректно. Речь идет, в частности, о многих индикаторах из ftp://ftp.quik.ru/public/INDICATORS.zip, если их использовать "как есть".
Проблема в том, что после включения фильтра по времени "в первом прогоне" Quik вызывает OnCalculate() для всех свечек, как если бы фильтра не было, но для тех свечек, что должны быть исключены фильтром, он, в ответ на вызов любой из функций для доступа к источнику данных O, H, L, C, V, T, выдает 0. После же того, как пользователь каким-либо способом заставит quik вновь запустить цикл полного перестроения индикатора (например, вышеописанным открытием окна настроек), цикл вызовов OnCalculate() происходит корректно: вызовы делаются только для свечек, отобранных фильтром по времени.
В принципе, ничего сложного в том, чтобы обойти эту проблему при написании своего индикатора нет, но в некоторых случая приходится прибегать к нетривиальным решениям (например, для AMA).

Я недавний пользователь quik и, возможно, еще не совсем освоил тонкости его настройки.

Подскажите, пожалуйста, такая проблема может быть вызвана какими-то моими кривыми настройками где-нибудь в Система->Настройки->... или это bug, который имеет смысл поправить разработчикам?