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

Egor Zaytsev,

добрый день!
Спасибо за комментарий.
Когда можно ожидать ответы на остальные вопросы?

Возник еще один вопрос.
8) Вы пишете: Допустим, у клиента имеется два рабочих места с uid = 102 и 107, к примеру. Пришла запись с биржи, которая не содержит uid, сервер QUIK отправляет ее сразу же "в сыром виде" пользователю, допустим, на рабочее место с uid = 102. Исходя из ваших слов, на второе рабочее место - с uid = 107 - отправки не произойдет. Но, если после того, как сервер QUIK отыщет в своей базе uid, с которого и была отправлена заявка, на которую пришел вызов OnOrder(), выяснилось, что этот uid = 107, а отнюдь не 102, на который произошла отправка "сырой" записи, то какой смысл в той самой - первой - "сырой" отправке? Рабочее место с uid = 107 все равно получит "свой" вызов OnOrder() только после проставления в биржевую запись <uid = 107>, а рабочему месту с uid = 102, первая полученная - "сырая" - запись с биржи не нужна вовсе, равно как и с проставленным uid, поскольку этот конкретный вызов OnOrder() - "чужой" для данного рабочего места  c uid = 102.
Тогда какой вообще смысл в той - первой - "сырой" отправке без uid, trans_id, флагов и т.п.? Ведь адресат может быть неправильный, и рабочее место должно будет отбраковать и отбракует не "свою" пришедшую запись.

Дополнительно еще один вопрос к разработчикам:

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

Egor Zaytsev,

прошу дать ответы еще на ряд вопросов:

5) Правильно ли изложена мною схема взаимодействия сервера QUIK у брокера и рабочего места пользователя в пунктах 1, 2 и 3 в моем сообщении #2? Если есть какие-то неточности или ошибки, равно как и дополнения, прошу изложить.
6) Относительно вашего ответа на вопрос по функции OnOrder().
  Если мы рассматриваем  в качестве условного отдельного момента времени изменение состояния заявки, то я вижу возможность наступления такого изменения в следующих случаях:
6.1) произошло изменение состояния заявки на бирже и пришла очередная запись с биржи (заявка только что зарегистрирована, заявка частично исполнена, заявка снята и другие варианты биржевых результатов);
6.2) произошло изменение состояния заявки на сервере QUIK в результате действий брокера (изменились флаги состояния, проведена переоценка возможности дальнейшего исполнения заявки и изменились "правила" брокера и т.п.);
6.3) произошло изменение состояния заявки на сервере QUIK в результате внутренних процессов и преобразований самого сервера QUIK как программного комплекса.
  Можно ли уверенно сказать, что при любом подобном - "удельном" - изменении состояния заявки функция OnOrder() будет вызвана НЕ БОЛЕЕ ДВУХ раз? Если это не так, то прошу указать, какое максимальное количество вызовов OnOrder(), относящихся к одному конкретному изменению состояния заявки может произойти.
7) Может ли вызов OnTrade() придти раньше вызова OnOrder() по одной и той же заявке? Прошу прокомментировать случаи:
7.1) заявка только что зарегистрирована торговой системой биржи;
7.2) произошло очередное частичное исполнение заявки;
7.3) произошло изменение состояния сделки на бирже.

_sk_,
спасибо за ссылку, ознакомился.

И еще один вопрос также к разработчикам.

Если я правильно понимаю, то в ситуации с несколькими вызовами OnOrder и OnTrade на данный момент картина такая:
1) Приходит запись с биржи, в которой пользователя идентифицирует только client_code. Информация о пользовательском номере транзакции trans_id и идентификаторе пользователя uid (код рабочего места в нумерации конкретного брокера) хранится на сервере QUIK у брокера и на биржу при выставлении заявки не отправляется. Соответственно, этих параметров в записи, пришедшей на сервер QUIK с биржи, нет.
2) Сервер QUIK сразу же отправляет запись, пришедшую с биржи, пользователю в соответствии с имеющимся в биржевой записи параметром client_code - по ВСЕМ кодам uid рабочих мест клиента, зарегистрированных у данного брокера. Для обычных - не корпоративных - пользователей такой uid обычно один, в связи с тем, что немногие пользователи - физические лица работают сразу с двумя и более рабочими местами. Но для корпоративных клиентов брокера наличие нескольких рабочих мест и, соответственно, нескольких uid - дело обычное.
3) После отправки биржевой записи, детализированной только в части кода клиента client_code, сервер QUIK проводит поиск по своей базе данных, где определяет какому uid соответствует пришедшая биржевая запись, и уже по реестру заявок с этого uid, находит нужную, соответствующую пришедшей биржевой записи, берет из нее дополнительно trans_id, flags и какие-то еще специфические для сервера и терминала данные, вставляет их в ту самую пришедшую с биржи запись и отправляет ее пользователю с client_code на уже один конкретный, а не на все пользовательские как при первой отправке, uid, при этом в отправляемой клиенту записи стоит trans_id, в случае, если таковой параметр был задан пользователем изначально - т.е. при отправке транзакции через программный уровень, либо поле trans_idстоит равным 0, если заявка изначально была отправлена, к примеру, вручную с терминала.
4) В результате к пользователю приходит следующий комплект:
- ОДНА запись, приводящая к ОДНОМУ вызову OnTransReply(), если транзакция передавалась программным способом;
- ДВЕ записи, приводящие к ДВУМ вызовам OnOrder() при каждом изменении состояния заявки на бирже;
- ДВЕ записи, приводящие к ДВУМ вызовам OnTrade() при получении с биржи каждой новой сделки пользователя (пусть и в результате частичного исполнения исходной заявки);
- ОДНА или более записей, приводящих к ОДНОМУ или более вызовам OnTrade(), если состояние конкретной сделки изменилось в результате записи, пришедшей с биржи, либо в результате изменения на сервере QUIK у брокера - как в результате действий самого брокера, так и в результате внутренних процессов сервера QUIK.

Посему и вопросы к разработчикам:
1) Может ли OnTransReply() быть вызван ДВА раза? Если да, то в каких случаях?
2) Может ли OnOrder() быть вызван ТРИ раза или более? Если да, то в каких случаях?
3) Какое максимальное количество вызовов OnTrade() может быть совершенно в условно отдельный момент обработки информации о новой сделке (биржевая запись + информационные преобразования на сервереQUIKу брокера)?
4) Планируется ли, возможно ли увеличение в обозримом будущем количества вызовов указанных QLUA-функций^ OnTransReply(), OnOrder(), OnTrade()?

Все изложенное мною и все заданные вопросы относятся ТОЛЬКО к штатной работе терминала и сервера QUIK.
Ситуации падения терминала, падения сервера QUIK, проблем со связью, с работой брокера либо с работой биржи - просьба НЕ РАССМАТРИВАТЬ.

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

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

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

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

Сергей, вы не совсем правильно меня поняли.
Вопрос не в том, что нельзя добавить строки после появления таблицы, а в том, что несмотря на СОЗДАННУЮ  и, соответственно уже существующую в памяти таблицу, добавлять в нее строки  можно только при открытом окне. Т.е., даже в целиком созданную и зарегистрированную таблицу нельзя добавить строки, если эта таблица не отображена на экране. А этого быть не должно, поскольку вопрос отображения - это вопрос перерисовки инвалидированной области, и никак не связан с логикой добавления/удаления строк. Вот, про это я и писал.

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

Кстати, в ваших комментариях к функции IsWindowClosed() указана любопытная вещь, что если окно таблицы было закрыто - т.е. исчезло из области видимости на экране, то его вновь можно вернуть в открытый вид функцией CreatreWindow(). Это означает, что до вызова DestroyTable() таблица - как логический объект - в области данных терминала существует. В этой ситуации вообще становится странным, почему фактор наличия открытого окна каким-то образом влияет на добавление новых строк в область данных терминала (они же уже есть и прекрасно себя чувствуют!).

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

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

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

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

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

Это относится к задаче оптимизации работы скриптов.
Стандартная практика в программировании - это формирование образа данных в памяти и лишь затем отображение содержимого. Если у меня имеется функция по добавлению строк, которая может быть вызвана из разных мест скрипта, то при текущем положении дел мне требуется каждый раз осуществлять либо контролирующий вызов IsWindowClosed(), либо иным образом отслеживать наличие открытого окна таблицы. К чему это приводит:
1) дополнительные ненужные затраты времени - что, возможно, не так заметно при нативном коде, но существенно увеличивает затраты в случае, когда используется скриптовый код, виртуальная машина и имеется необходимость обеспечивать максимальное быстродействие кода в режиме реального времени, а также с учетом возможных многократных - за короткий промежуток времени - операций добавления/удаления строк в таблице.
2) нарушение стандартной логики ООП, когда механизм отображения/обновления данных не связан с процессом удаления/добавления данных в объект.

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

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

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

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

bulat,
не совсем понятно, чего вы хотите.
Если вас интересует вариант кода для перебора элементов таблицы, то для этого существуют функции lua: pairs() и ipairs().
Пример:
for  k, v in pairs(array)  do  message(tostring(k)..": "..v)  end
при условии, что array = { "SBER", "LKOH"  }  или т.п. В результате вы получите серию сообщений вида "1: SBER".

Алексей,
лимит у терминала QUIK - приблизительно 3000 интервалов для хранения в качестве истории. На разных инструментах может варьироваться от 2980 до 3100. Точнее не скажу, можете проверить экспериментально. Если у вас на компьютере гарантированно находится информация о 4000 интервалов, то все равно лимит будет в диапазоне от 2980 до 3100. Поэтому в данном случае по вашему инструменту номер последней свечи все время будет один и тот же, просто будут меняться ее характеристики OHLCV.

Терминал QUIK при наличии пришедших с сервера данных хранит примерно 3000 записей - т.е. примерно 3000 свечей. Это означает, что если история инструмента на вашем рабочем месте содержит, скажем, 3060 свечей (с 10-00 до 18-45) мы имеем 9 часовых интервалов в сутки) - т.е. историю за 340 торговых дней, - то да, номер последней свечи будет один и тот же, так как нумерация идет в возрастающем порядке и ограничивается лимитом примерно в 3000. Есть ли возможность поставки через CreateDataSource() данных только за последний торговый день - это уже вопрос к разработчикам.

Космонавт,
похоже вы плохо представляете себе работу информационных потоков с биржи.

1.Данные в терминал в любом случае поступают последовательно. Просто, если у вас заказаны 10 инструментов, это визуально и по временнЫм ощущениям может трактоваться как параллельный приход данных по всем инструментам. Если же заказанных инструментов будет 30, а тем более под 100, то последовательность данных начнет проявляться.
2. Поток биржевой информации сначала - в течение определенного времени - поступает к вашему брокеру, затем проходит обработку на сервере брокера, так как сервер выделяет для отправки вам именно те инструменты, что вы заказывали. И только потом идет отправка на ваш терминал пользователя.
Скорость поступления биржевого потока на сервер брокера определяется возможностями канала, связывающего сервер брокера с биржевым шлюзом + аппаратные возможности сервера брокера в части скорости обработки поступающей информации. При общих равных условиях можно считать эту величину более-менее совпадающей со скоростью поступления информации, если бы вы напрямую были подключены к биржевому шлюзу (тот же сервис Plaza).
Скорость обработки поступившей с биржи информации зависит уже исключительно от того, какие механизмы и нагрузки действуют на сервере вашего брокера. Одно дело - если ваш брокер просто делает выборку по запрошенным инструментам и сразу отправляет ее на ваш терминал клиента, и совершенно другая ситуация, если ваш брокер перед отправкой информации вам по умолчанию проводит  различные тесты и процедуры, которые могут существенно увеличивать величину задержки информации на сервере перед тем, как отправить ее вам. Этот показатель зависит исключительно от особенностей сервера и ПО вашего брокера.
Наконец, скорость обработки поступающей в ваш терминал информации зависит от скоростных характеристик вашего канала связи с брокером и от объема тех субзадач, что включены вами в рамках основного рабочего сеанса на вашем терминале клиента. Этот показатель целиком и полностью определяется вашим провайдером в части скорости информационного прохождения канала, вашим "железом" и количеством тех задач, что вы  выполняете в вашем терминале QUIK.
3. Если вы ставите перед собой задачу добиться минимальной скорости взаимодействия с биржей, то выход только один: арендовать у Мосбиржи подключение к биржевому шлюзу, поставить FIX-интерфейс и собственное ПО по получению и отправке информации. В этом случае вы получите скорость обмена данными как у брокера непосредственно с биржей, а скорость обработки информации вашим клиентским местом будет определяться характеристиками вашего компьютера и оперативностью реагирования вашего ПО. Но в финансовом плане - это самый затратный способ.

Маржинальный фьючерс - это что-то уж совсем экзотическое. Вы собираетесь торговать с плечом 50?
Фьючерс сам по себе (как финансовый инструмент) обеспечивает маржинальную торговлю с диапазоном плеча от 5 до 10.  Если же вы хотите еще кратно увеличить уже имеющееся плечо... Не слишком  ли большой риск?

PS.
Даже если принять, что ваш брокер ориентируется по времени физических биржевых платежей, которые осуществляются до 17-30мск в режиме "T0", а остальные - уже врежиме "Т+1", включая и период времени с 17-30мск до 18-45мск, все равно: очень странная ситуация.

Космонавт,
проблема, похоже, не у вас, а у брокера, а именно: отсутствие должного резерва денежных средств на биржевом счету брокера для блокирования биржей вашего ГО. Т.е. условно говоря, в конце дня кто-то из клиентов вашего брокера встает в очень большую по объему позицию и забирает под себя все лимиты ГО. Соответственно, пока ваш брокер физически не "дольет" ликвидность  (т.е. рубли) на свой биржевой счет, биржа выдает сообщение "превышен лимит". Код ошибки сейчас не помню. Выхода только два: либо ждать вечернего клиринга Мосбиржи, либо просить брокера "долить" ликвидность.
Иногда такая вещь происходит, если брокер сам в конце торгового дня встает в крупную позицию (о целях рассуждать не будем).
Странный у вас брокер, однако, если такая вещь случается постоянно.

Еще один вариант может быть - хотя и очень редкий - если относительно вашей клиентской записи поставлен режим особых условий расчета. Поясню.
На срочном рынке режим расчетов "Т+2" применяется редко. В основном расчеты идут в режимах "Т0" и  "Т+1". Если вы проводите офсетные сделки с 10-00мск до 18-45мск, то режим "Т0", так как расчет идет в вечерний клиринг с 18-45мск до 19-05мск. Если же торгуете с 19-05мск до 23-50мск, то режим "Т+1", так как  фактический расчет будет лишь во время очередного вечернего клиринга - т.е. на следующий день. Для чего вашему брокеру выставлять по вашим операциям режим "Т+2" - т.е. с отсрочкой платежей еще на сутки - непонятно.

В любом случае, нужно сначала решить эту проблему с брокером.

Zoya Skvorcova,
добрый день.

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

Попробуйте получить данные через callback-функцию OnTrade (возвращает только ваши сделки). Фактическая цена купли/продажи указана в поле price. Но имейте в виду, что объем запрошенный вами на приобретение по рыночной цене, может быть реализован посредством нескольких сделок с разными фактическими ценами и объемами, хотя их суммарный объем будет совпадать с указанным в заявке.

1) У вас перед OnTransReply() стоит какой-то end: непонятно, к чему он относится.
2) Часть кода, которая отвечает за покупку почему-то вообще стоит вне функции main(). Поместите ее внутрь основного блока main(), но до цикла while.

Скорее всего, только проверкой времени операции. Если после 19-00, то уже следующий день

s_mike,
уже пробовал - никак. SetSelectedRow(t_id, 0) выдает ошибку (-1) в качестве результата.

Еще один вопрос к разработчикам.

Выделение конкретной строки в таблице, при нажатии на нее, зачастую вообще не нужно. Тем не менее, это выделение отсутствует с момента создания таблицы и только до тех пор, пока не произойдет нажатие на конкретную строку таблицы. Потом его убрать уже невозможно.
Есть ли средство как-то вообще отменить механизм выделения, чтобы этот прямоугольник по периметру строки не появлялся? Что-то наподобие:
_SetSelectionMode(true)_ или _SetSelectionMode(false)_

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

Sergey Gorokhov,
я вас понял.

Тогда прошу включить в документацию по QLUA в описание события QTABLE_LBUTTONDOWN дополнительный текст о том, что сразу же после обработки данного события терминал QUIK обрабатывает событие QTABLE_SELCHANGED с теми же самыми параметрами par1 (строка) и par2 (столбец), что передавались в обработчик события QTABLE_LBUTTONDOWN. Результат обработки события QTABLE_SELCHANGED терминалом фактически эквивалентен скрытому вызову SetSelectedRow (t_id, par1).

Sergey Gorokhov,
вы не правы. Поясню.

1. Нюанс заключается в том, что функция SetSelectedRow() не приводит к визуальным изменениям в приведенном мною конкретном случае не из-за моего кода или моей логики, а из-за того, что при нажатии на строку созданной таблицы - вне зависимости от кода обработки события QTABLE_LBUTTONDOWN - терминал QUIK обрабатывает событие QTABLE_SELCHANGED, хотя не должен этого делать в случае успешной отработки функции SetSelectedRow().
Если говорить совсем уже конкретно, то программный код QUIK при обработке связанного (а оно именно связанное, так как генерируется в данном случае при нажатии на левую кнопку мыши и только после события QTABLE_LBUTTONDOWN) события QTABLE_SELCHANGED должен проверять был ли вызов SetSelectedRow() в процессе обработки события QTABLE_LBUTTONDOWN. И если был, то передача события QTABLE_SELCHANGED для дальнейшей маршрутизации (routing) должна прекращаться, то есть событие QTABLE_SELCHANGED далее не маршрутизируется.
Вообще говоря, логика кода QUIK должна быть такой, что терминал генерирует событие QTABLE_SELCHANGED не как обязательное после QTABLE_LBUTTONDOWN, а как дополнительное - только в случае, если событие QTABLE_LBUTTONDOWN обрабатывается по умолчанию - в собственной процедуре терминала - при отсутствии пользовательской процедуры обработки этого события. Тогда - да, терминал по умолчанию сгенерирует и обработает событие QTABLE_SELCHANGED, так как ему вздумается.

2. Вопрос не в воображении. Если в официальной документации что-то не описано, то вы - разработчики - в любой момент можете ту или иную особенность поведения терминал изменить или отменить, и пользователь даже может не понять в чем дело, так как его скрипт нормально работал, а вышла новая версия - и скрипт вдруг не работает. Начинаются судорожные поиски, в чем проблема, работа стоит, и все это "зависает" до тех пор, пока вы не сможете сказать точно, что "вот, этот кусок вашего кода может не работать в новой версии".

3. Вопрос я частично уже пояснил в пункте 1. Выскажусь по еще одной особенности терминала QUIK. Вообще-то нормальной цепочкой при работе под Windows любого приложения при нажатии на левую кнопку мыши является цепочка из ДВУХ событий, генерируемых самой ОС:
- событие <LBUTTONDOWN>,
- событие <LBUTTONUP>.
Если бы на одном уровне маршрутизации QUIK обрабатывал только эти 2 события, описанной мною проблемы не было бы в принципе. Но действующий программный код QUIK "вклинивает" между ними еще одно событие QTABLE_SELCHANGED, которое принудительно изменяет/отменяет действие пользовательского вызова SetSelectedRow(). Зачем это нужно - непонятно. Но уж коль оно так устроено в коде терминала, сделайте соответствующее описание этой особенности в официальном руководстве по QLUA.

Старатель,
огромное вам спасибо! Вариант вызова SetSelectedRow() после события QTABLE_LBUTTONUP приводит к требуемым визуальным изменениям.

---

Вопросы к разработчикам:
1) Почему в документации по QLUA ни слова нет обо всех этих нюансах?
2) Почему в документации по QLUA не документированы полные цепочки генерируемых событий при тех или иных нажатиях клавиш, кнопок?
3) Почему вызов SetSelectedRow() не отменяет (и не снимает)  генерацию (обработку) события QTABLE_SELCHANGED?

Рабочее место QUIK версии 7.5.0.72.

Текст скрипта прислать не могу, но могу указать примерный состав кода:
1) <Создание стандартной таблицы с идентификатором t_id, 3 столбцами и 12 строками>
2) добавляем в функцию создания таблицы следующий код
   SetWindowCaption(t_id, "ААА")
   SetWindowPos(t_id, 0, 0, 210, 320)
   SetTableNotificationCallback(t_id, funcCallback)
   Содержание таблицы не имеет значения.
3) Определяем callback для обработки событий:
   local function funcCallback(t_id, msg, par1, par2)
       if  (msg == QTABLE_LBUTTONDOWN)  then
          local  r = SetSelectedRow(t_id, 12)
           message("SetSelectedRow returns "..tostring®)
      end
   end
4) Запускаем скрипт и проверяем, последовательно нажимая на любые строки выше 12-й. Выделение на 12-ю строку не перемещается, пока не нажмем на собственно строку 12.

Возникла следующая проблема:
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?