Andrei2016 (Автор тем)

Вопрос к разработчикам.

Заметил такую особенность: далеко не всегда обновление пользовательской таблицы/окна происходит сразу же после изменения содержимого одной или нескольких ячеек. Причиной может быть:
1) установленная периодичность обновления пользовательских таблиц - как внутренний параметр терминала QUIK. В этом случае вопрос: какое значение имеет этот параметр (в миллисекундах, секундах или еще каким-то образом измеримый);
2) захват на определенное время контроля за таблицей/окном со стороны основного либо клиентского потока (при вызовах SetCell в разных потоках) с блокированием доступа (и соответственно процедуры обновления) из другого потока. Если да, то вопрос: как можно снять такую блокировку?
3) блокировка обновления самим механизмом функционирования пользовательских таблиц/окон.

Неясно также и то, что именно блокируется: инвалидация области окна или же процесс отображения таблицы в окне.
Прошу дать пояснения.

Еще один вопрос: периодически (особенно в период медленного обновления таблицы текущих торгов после 19-00) происходит отбраковка функции SetCell: функция вовзращает false при стандартном занесении строки в столбец с типом STRING.
Прошу дать ответ на вопрос: в каких ситуациях функция SetCell возвращает значение false и не производит изменение содержимого ячейки. Ситуация с несоответствием передаваемого значения типу столбца рассматривать не нужно: все столбцы имеют тип STRING, при этом передаваемое по SetCell значение - также строковое.

Прошу прощения, если данный вопрос уже обсуждался ранее.
Вопрос к разработчикам.

Допустим, у меня есть данные по апрельскому фьючерсу, срок которого истек 1 мая. Начиная с 1 мая, подключения терминала к действующим торгам не было, анализ производился на открытом графике и данных апрельского фьючерса в архивных данных терминала. Если я сейчас подключусь к торгам, то QUIK предложит мне заменить апрельский фьючерс майским, при этом из списка доступных для открытия графика инструментов апрельский фьючерс исчезнет, даже если в архивной папке будут находиться его сохраненные данные. Если я откажусь заменить инструмент и решу сделать это вручную, то список доступных инструментов все равно обновится и апрельский фьючерс из него также исчезнет.
Вопрос в том, могу ли я сделать так, чтобы при сохранении архивных данных, подключении к серверу и получении данных по майскому фьючерсу, апрельский фьючерс:
а) не исчезал из списка доступных инструментов;
б) мог быть открыт на графике, на основании архивных данных, даже в условиях открытия в соседнем графике майского фьючерса.

Если ответ "да", то прошу указать, как это сделать. Поиск разъяснений в документации результатов не принес.

Возник очень любопытный и очень неприятный эффект. Суть в следующем.
Запускаю один единственный скрипт, открыт один график, открыт один источник данных. Сессия закрыта, помех связи нет. Дальше самое интересное.
Есть функция, назовем ее func() такого вида:

local function func()
local x, y, z, param
-- Присваиваются значения переменным y, z, param. Все значения - целочисленные (integer).
x = (y-z)*param  -- результат в x тоже целочисленный
-- некоторые действия, которые не изменяют значений всех четырех переменных
-- Вторично присваиваются значения переменным y, z, param. Все значения - целочисленные (integer).
x = (y-z)*param  -- снова результат в x тоже целочисленный
-- некоторые действия, которые не изменяют значений всех четырех переменных
-- Снова (уже в третий раз) присваиваются значения переменным y, z, param. Все значения - целочисленные (integer).
x = (y-z)*param  
-- результат в x оказывается числом с плавающей точкой (double). Ошибка в расчетах!
end

Эффект проявился впервые. В документации по Lua сказано, что интерпретатор знает, какой должен быть тип у результата арифметической операции, в зависимости от операнда. Здесь же получается, что все операнды - целочисленные, но результат или получается или остается типа double.
Сооружать костыли в виде постоянного использования math.floor как-то не хочется.
Есть ли у кого помимо разработчиков какие-то соображения, почему такое могло случиться? Были ли у кого подобные "фокусы".

PS.
Была бы в Lua четкая типизация данных, такого эффекта не могло бы быть в принципе.
Жаль, что все идет в виде union.

Вопрос-пожелание.

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

Проанализировав таблицы терминала, я пришел к выводу, что во всех случаях используется один и тот же класс, задающий рабочую таблицу. Отличие же пользовательских таблиц, созданных через QLUA, от таблиц собственно терминала только в наличии ряда ограничений по функциональности (de facto, в отсутствии наследования ряда методов класса при создании пользовательской таблицы). Тем не менее, наличие столбца с номерами строк и автоматическая их нумерация - свойство абсолютно всех таблиц терминала, как пользовательских, так и всех остальных. Возможность вручную уменьшить ширину этого столбца до нуля говорит о том, что в конструкторе класса, описывающего таблицу, имеется опция по установке изначальной ширины этого столбца - отличной от нуля, а при дальнейшей работе обрабатывается событие изменения ширины этого столбца с сохранением новой величины в отдельной переменной класса.

В связи с этим повторный вопрос-пожелание.
Прошу добавить в формат вызова функции AllocTable() дополнительный параметр - скажем, ZeroColumnSize, - который может принимать значения 0 и больше нуля. По умолчанию, т.е. при отсутствии указания этого параметра в вызове функции, сохраняется нынешняя последовательность действий в плане создания таблицы - т.е. с некой изначально ненулевой шириной столбца номеров строк. Если же параметр указан, то задается именно та ширина столбца номеров строк, которая указана. Режим формата функции "по умолчанию" обеспечит совместимость созданных к настоящему моменту пользовательских скриптов без необходимости их доработки в части вызовов AllocTable().
Если нет возможности добавить целочисленный параметр функции, то можно сделать вариант, скажем, NoZeroColumn со значениями "true / false", где значение false берется по умолчанию и означает стандартную схему создания столбца с номерами строк. Значение же true будет означать задание нулевой ширины этого столбца.

Если трогать формат вызова функции AllocTable() нежелательно, то прошу добавить в QLUA отдельную функцию, скажем, SetZeroColumnSize(number) или ShowZeroColumn(boolean), которую можно вызвать в любой момент, и которая как раз и будет переустанавливать ширину столбца с номерами строк.

Вопрос к разработчикам.

Столкнулся с очень странным эффектом при работе callback-функции OnOrder().
Картина следующая. Работает скрипт, выставляется заявка, отрабатывает. Далее следуют два вызова OnOrder() в ситуации, когда оба раза флаги показывают, что заявка снята. Но двойной вызов OnOrder() на СНЯТОЙ заявке - это еще ладно, проблема в другом.

Суть проблемы.
В скрипте создан массив, куда заносятся номера выставленных заявок. После того, как заявка снята, соответствующий элемент с order_num снятой заявки из массива исключается. СУЩЕСТВЕННО: обе операции - и включение в массив заявки , и исключение ее из этого массива происходят именно в OnOrder(), а не где-либо еще в скрипте.
Трассируя функцию OnOrder(), обнаружил, что почти мгновенно происходят ДВА ее вызова при снятии заявки ( lags показывает, что заявка снята), но при этом оба вызова, проходя через тело OnOrder(), отрабатывают, как если бы в первом вызове не было указано, что заявка на биржевом сервере уже снята, и она с ее order_num не была бы исключена из массива.

Я могу понять такую ситуацию, если допустить что два эти вызова OnOrder() происходят из РАЗНЫХ потоков. Тогда - да, возможна ситуация, что VM LUA еще не успела полностью отработать код OnOrder(), вызванный первым потоком, тогда как сразу же запустилось исполнение экземпляра OnOrder(), созданного для второго потока.
Но разработчики QUIK все время говорят, что ВСЕ вызовы callback-функций со стороны терминала происходят исключительно в главном (т.е. одном и том же) потоке терминала. В этом случае описанного мною эффекта достичь не получится, так как обработка второго вызова OnOrder() для уже снятой заявки произойдет только после полного завершения отработки первого вызова OnOrder(), который априори исключит  данную заявку по ее order_num из массива.

На мой взгляд возможны два варианта:
а) вызовы callback-функций, в том числе и OnOrder(), ДЕЙСТВИТЕЛЬНО происходят из разных потоков терминала, а не только из одного единственного  - главного; при этом очередность вызовов не предустановлена, и тогда руководство по QLUA и комментарии на форуме от разработчиков вводят нас в явное заблуждение.
б) разработчики не знают, какой конкретно поток внутри терминала может в конкретный момент времени - помимо ОСНОВНОГО потока рабочего места QUIK - вклиниться в цепочку вызовов callback-функций. И имеют в виду, что?, к примеру, вызов OnOrder() происходит не строго, а ПРЕИМУЩЕСТВЕННО в главном потоке терминала, что допускает такие вызовы и другими потоками терминала, в том числе и с неуловимой для VM QLUA задержкой по времени вызова.

Прошу разработчиков прокомментировать изложенное, и - либо подтвердить один из вариантов, либо опровергнуть.
Вопрос очень существенный.

Вопрос в первую очередь к разработчикам.

На данный момент у меня в терминале QUIK стоит настройка "Запрашивать данные каждые 10 секунд". Это означает, что частота обновления данных в терминале составляет не менее, чем 1 пакет/ 10 сек.

Допустим, я создал источник данных при помощи функции CreateDataSource(class, sec, interval). Значение param у меня не задано - соответственно, формирование массива баров происходит на основании таблицы обезличенных сделок.
Вопрос: если сделки по выбранному инструменту происходят с частотой выше, чем 1 сделка / 10 сек. - допустим, по сделке раз в 3 секунды, как поведет себя терминал в плане вызова установленной callback-функции?
а) терминал будет получать данные от сервера QUIK с установленной частотой - т.е. 1 пакет / 10 секунд, - что означает приход за период 10 секунд одного пакета с суммированной информацией по 3 сделкам. И, соответственно, callback будет вызван тоже только 1 раз за 10 секунд;
б) терминал будет получать данные от сервера QUIK с той частотой, с которой на сервер с биржи приходят очередные записи о сделках по инструменту - т.е. в рассматриваемом примере терминал получит 3 пакета за период в 10 секунд и так же 3 раза произведет вызов callback-функции источника данных в моем скрипте.

Какой из указанных вариантов действий является верным? Если есть какие-то особенности или дополнения, прошу изложить.

Вопрос в первую очередь к разработчикам, так как тесно связан с особенностями функционирования сервера QUIK.

Ранее группа поддержки уже упоминала о том, что возможна ситуация, когда сообщение об исполнении заявки - т.е. вызов OnTrade - поступит раньше, чем ответ на заявку - т.е. вызов OnTransReply. По данной теме одно существенное замечание: заявки выставляются клиентом ТОЛЬКО через программный уровень - т.е. через Lua-скрипт.

По логике последовательность вызовов должна быть жесткой:
OnTransReply --> OnOrder --> OnTrade (***).
Однако, замечание группы поддержки говорит, что возможны исключения из общих правил. Поэтому задаю главный вопрос:

в каких случаях может измениться порядок прихода с сервера и отработки терминалом callback-вызовов в сравнении с указанной очередностью (***)?
Если порядок прихода на терминал вызовов изменяется, то какова будет действительная очередность?
Прошу указать все возможные варианты при штатной работе терминала и сервера, т.е. при отсутствии обрывов связи терминала с сервером, сервера с биржей либо падения сервера/терминала.

Вопрос - в первую очередь - к разработчикам.

Для администрирования строк пользовательской таблицы есть функции создания и удаления стро:
InsertRow() и DeleteRow().
В то же время для добавления столбцов имеется лишь функция AddColumn() с ограниченным режимом действия, а функции удаления столбца нет.

Вопрос: почему нельзя сделать нормальное динамическое добавление столбцов в таблицу и их удаление в любой момент времени? Т.е., условно говоря, функции InsertColumn(), DeleteColumn().

При этом в режиме ручной работы с созданной скриптом таблицей удалить столбец можно в любой момент, а средствами QLUA почему-то нет. Можно, конечно, предложить вариант удаления таблицы и создания ее заново с новым набором столбцов. Но это означает потерю информации, потерю времени и уход в логику первых компьютеров IBM PC конца 80-х. Хотелось бы иметь средство более современное и динамичное.

Таки, возможны ли здесь какие-то варианты?  

Вопрос - в первую очередь - к разработчикам.

Уже давно наблюдаю странную вещь.
Допустим, в скрипте создана таблица рабочего места QUIK:
t_id = AllocTable(),
далее в таблицу добавлены столбцы серией вызовов AddColumn().
Если я после этого добавлю в таблицу несколько строк по InsertRow(), после чего произведу вызов:
CreateWindow(t_id), то никаких добавленных в таблицу строк у меня отображаться не будет.
И для того, чтобы строки отображались, необходимо, чтобы вызов CreateWindow() производился ДО процедуры добавления строк в таблицу.

Странно: для того, чтобы добавить в таблицу столбцы, вызов CreateWindow() - необязателен. Т.е. вроде как мы имеем дело с образом таблицы в памяти. Но для того, чтобы добавить строки, необходимо наличие именно ОТКРЫТОГО ОКНА таблицы - по команде CreateWindow(), и лишь потом можно добавлять строки, иначе результат - нулевой.

Почему нельзя добавлять строки в таблицу до открытия окна таблицы - аналогично добавлению столбцов?

Возникла следующая проблема:
1.Запускаю скрипт, который формирует пользовательскую таблицу.
2.Информация в пользовательской таблице отображается нормально, сбоев нет.
3.В обработчике события QTABLE_LBUTTONDOWN поставлен вызов SetSelectedRow(t_id, 12).
4.Проверяю работу вызова SetSelectedRow() с разными значениями от 1 до 12 - возвращает номер запрашиваемой строки: т.е. функция сигнализирует об успешном выполнении.
5.Тем не менее, визуально в таблице выделяется лишь та строка, при нажатии на которую произошло это событие. Т.е., допустим, у меня записано SetSelectedRow(t_id, 12), а левую кнопку мыши я нажимаю, когда курсор находится на строке 7. В результате функция возвращает значение 12, но в таблице по-прежнему выделена именно строка 7. И перевести выделение на строку 12 я могу только тогда, когда именно на строке 12 нажму левую кнопку мыши.

Вопрос в первую очередь к разработчикам:
почему срабатывание функции  SetSelectedRow() не приводит к каким-либо визуальным изменениям в указываемой таблице?

Не знаю, был ли уже такой вопрос, но спрошу.

Могу ли я "прикрутить" к рабочему QUIK'у поток (обновляемый) "собственных" котировок? Т.е., не официальных биржевых, а просто тестовых, к примеру. Обозначить их как инструмент с тикером таким-то, чтобы можно было их отобразить средствами самого терминала.
Необходимость связана с тем, что мне, допустим, нужен график по инструменту, но, к примеру, "сглаженный", т.е. с трансформированными по некой формуле котировками. При этом нужно отображение со всеми атрибутами диаграмм и графиков QUIK'а: в виде свечей или баров, с сеткой или без оной и т.п.
Если такой сервис имеется, то вопрос второй: возможно ли формировать/перехватывать поток таких котировок через Lua?