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

Страницы: 1
RSS
Проблема с функцией SetSelectedRow()
 
Возникла следующая проблема:
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 версии 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.
 
Цитата
Andrei2016 написал:
почему срабатывание функции  SetSelectedRow() не приводит к каким-либо визуальным изменениям в указываемой таблице?
Возможно, потому, что при нажатии на левую клавишу мыши срабатывают сразу три события: QTABLE_LBUTTONDOWN, QTABLE_SELCHANGED, QTABLE_LBUTTONUP
Т.е., событие QTABLE_SELCHANGED возвращает выделение на нажатую строку после вашей функции funcCallback.
Попробуйте так:
Код
if (msg == QTABLE_LBUTTONUP) then 
  local r = SetSelectedRow(t_id, 12) 
Надо делать так, как надо. А как не надо - делать не надо.
 
Старатель,
огромное вам спасибо! Вариант вызова SetSelectedRow() после события QTABLE_LBUTTONUP приводит к требуемым визуальным изменениям.

---

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

Цитата
Andrei2016 написал:
2) Почему в документации по QLUA не документированы полные цепочки генерируемых событий при тех или иных нажатиях клавиш, кнопок?
ситуации вида "что будет если" не описываются в документации, потому что такой список ограничен только воображением.

Цитата
Andrei2016 написал:
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.
 
Andrei2016,
1) Это только Ваше мнение. Наша реализация от него отличается. Не видим причин менять реализацию.
2) Для таких случаев существует список изменений, который присутствует в каждом обновлении.
3) Да мы добавили свое событие и срабатывает оно после LBUTTONDOWN. Это наше право как разработчика, так как аналога события QTABLE_SELCHANGED в стандартных функциях Windows нет, а оно нужно.
 
Sergey Gorokhov,
я вас понял.

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

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

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

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

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

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Цитата
s_mike@rambler.ru написал:
В качестве идеи: попробовать установить выделение на нулевую строку.
s_mike,
уже пробовал - никак. SetSelectedRow(t_id, 0) выдает ошибку (-1) в качестве результата.
 
Цитата
Andrei2016 написал:
Еще один вопрос к разработчикам.

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

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

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

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

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