Проблема с функцией SetSelectedRow()

Рабочее место 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.

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

---

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

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.

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

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

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

В качестве идеи: попробовать установить выделение на нулевую строку.  

Добрый день,

На данный момент такая возможность отсутствует.
Ваше пожелание относительно ее реализации зарегистрировано.  Мы постараемся рассмотреть его и  сообщить Вам результаты анализа. Впоследствии, по результатам анализа,  будет приниматься решение о реализации пожелания в будущих версиях ПО.

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

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