![]() |
#1 |
Мрачный тип
|
Игрища с позиционированием выделенной записи среди видимых строк grid'а
Коллеги , может кто занимался подобным и сможет подсказать что дельное ...
Ситуация - есть grid с определенной видимой выделенной строкой, на источнике данных которого запускается обновление набора данных через research() и восстановление выделенной позиции через FindValue()/FindRecord(). В случаях, когда перед таким обновлением и восстановлением выделенной позиции : а) выделенная позиция имела, скажем так, порядковый номер в выводимом наборе данных, не превышающий кол-во видимых строк в grid б,) выделенная позиция имела порядковый номер в выводимом наборе данных, превышающий кол-во видимых строк в grid, но среди видимых строк grid'а стояла на последнем месте то после обновления состояние выделения в grid и место выделенной позиции среди видимых строк grid'а не меняется. Во всех остальных случаях - позиция выделения, будучи корректной в части позиции в наборе данных, позиционно прыгает" среди видимых строк grid'а вниз, вызывая некий визуальный дискомфорт. В принципе, данное поведение понятно и технически логично, но хотелось бы, по возможности, от этого избавиться. Можно ли как-то перед таким обновлением считать у выделенной позиции ее текущее положение среди видимых на гриде строк и после обновления, если положение изменилось, вернуть его в первоначальное состояние (доскроллировать grid на нужное кол-во строк вниз) ? У источника данных все "позиционные" методы касаются именно позиции выделения в наборе данных и к позиции среди видимых строк на grid'е не имеет отношения, на методах grid'а тоже ничего нарыть не смог и в поиске по форуму не удалось ничего нарыть ![]()
__________________
Мы летаем, кружимся, нагоняем ужасы ... Последний раз редактировалось TasmanianDevil; 12.03.2021 в 12:14. |
|
![]() |
#2 |
Участник
|
У research параметр есть retainPosision
по умолчанию false НО! сама постановка - восстанавливать позицию мне кажется чертовски запоутывающей пользователя. пользователю скорее нужно "остаться на той же самой записи, но возможно в другой позиции", а не в "той же самой позиции, но возможно на другой записи" насколько я помню, research(true) оставит курсор как раз на записи с тем же самым recId. но это не точно ![]() в любом случае, мне кажется, что НЕ нужно привязываться ни к позиции в курсоре, ни тем более к позиции в гриде. |
|
![]() |
#3 |
Мрачный тип
|
А этого никому и не надо.
Надо именно на той же выделенной записи и чтобы эта выделенная запись не "прыгала" по гриду в части своей позиции среди видимых после обновления. Цитата:
Немного уточню решаемый предмет- данный вопрос возник в финале реализации с помощью grid не особо "любимого" Вами "дерева", по сути - косметическая "рюшечка", не особо портящая результат. Возникает данный вопрос при свертке/развертке узловой записи - хотелось бы после обновления набора данных, связанного с отрисовкой добавляемых/ скрываемых подчиненных позиций, лежащих ниже выделенного узла, чтобы сам узел не менял своего положения среди видимых строк грида (см.. вложение) Конечно же, даже сам оригинальный FromTreeControl грешен всяким в части прыжков выделенной позиции среди видимых элементов(при развертывании приыгает вверх, при свертке - вниз), но хотелось добиться более "спокойного" поведения
__________________
Мы летаем, кружимся, нагоняем ужасы ... Последний раз редактировалось TasmanianDevil; 12.03.2021 в 13:57. |
|
![]() |
#4 |
Участник
|
Насколько я помню, retainPosision не гарантирует что это будет та же запись. Если после выполнения запроса изменилась выборка то запись может быть другой.
Если нужно гарантировать что та же запись будет, то я делал в 2009-й некий финт. Выставлял сортировку по какому-то уникальному полю (RecId или другой ключ) Ставил нужное значение в element.args().lookupField и element.args().lookupValue - по уникальному полю для которого поставили сортировку. Делал research Позиционирование работало быстро. Дальше можно вернуть оригинальные значения у измененных параметров. В 2012-й можно попробовать поиграть с lookupRecord() - я сам не пробовал. |
|
|
За это сообщение автора поблагодарили: mazzy (2), sukhanchik (3). |
![]() |
#5 |
Участник
|
Цитата:
Сообщение от TasmanianDevil
![]() Немного уточню решаемый предмет- данный вопрос возник в финале реализации с помощью grid не особо "любимого" Вами "дерева", по сути - косметическая "рюшечка", не особо портящая результат.
Возникает данный вопрос при свертке/развертке узловой записи - хотелось бы после обновления набора данных, связанного с отрисовкой добавляемых/ скрываемых подчиненных позиций, лежащих ниже выделенного узла, чтобы сам узел не менял своего положения среди видимых строк грида (см.. вложение) ![]() поэтому и не особо любим лично мной. а если набор данных изменился в другой аксапте. то узел тоже не должен менять своего положения? предположим, нет аксапты. есть только ручка, бумага и воображаемый набор на десяток элементов. как ваша хотелка должна работать? |
|
![]() |
#6 |
Мрачный тип
|
Цитата:
Цитата:
Допустим , что есть для воображаемого набора воображаемый grid c 5 видимыми строками для вывода элементов. На гриде в текущий момент видны элементы, начиная с 5-го ( 5, 6, 7, 8, 9).и выделение текущей позиции стоит на 6-ом (2-й среди видимых на grid). Я раскрываю 6-й элемент (lдопустим , у него 2 подчиненных) . и хочу увидеть следующую картину видимых на grid элементов после обновления - 5, 6, 6.1, 6.2, 7 с выделением на 6-ом (т.е. точно так же выделение остается на той же записи и эта запись имеет ту же самую позицию среди видимых на grid) Что получается при вызове research()/FindValue() ? research() обновит набор данных (станет 1, 2, 3, 4, 5, 6, 6.1, 6.2, 7, 8, 9, 10) отобразит на grid набор видимых строк с 1 по 5.с выделением на 1-ом. FindValue() переместит выделение на элемент 6 и изменит набор видимых строки в grid со 2-го по 6-й.(скроллирует grid, пока не найдет искомую запись, которая оказывается последней среди видимых на grid ) - что несколько отличается от желаемой картины и визуально воспринимается как "прыжок".выделенной позиции и всех вышерасположенных данных вниз по grid'у. Как исправить такое - попытаться доскроллировать на нужное кол-во шагов сам grid после FindValue() так, чтобы выделенная запись обрела среди видимых ту же самую позицию, что и до обновления. Именно по реализации этого и есть вопрос - есть ли какие средства, позволяющие считывать и управлять позицией среди видимых строк для выделенной записи на grid
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
![]() |
#7 |
Участник
|
Цитата:
пока в рассматриваемом случае не будет вводной "другая аксапта изменяет набор данных" рассматривать бессмысленно. промоделируйте на пальцах что должно происходить, если набор изменился. куда и как нужно позиционировать и как сохранять позицию. если поведение измененного и неизмененного наборов будет отличаться, то зачем это нужно? ведь для пользователь не знает об изменениях и для пользователя все равно позиция будет иногда прыгать. |
|
![]() |
#8 |
Участник
|
Дабы вернуть дискуссию в конструктивное русло предположим что набор данных статичен и не подвержен изменению ни со стороны других пользователей ни со стороны текущего пользователя. Я думаю это вполне возможный сценарий
Нет, не то чтобы я ратовал за подобные извращения над пользовательским интерфейсом. Да, здесь больше спортивный интерес и чисто программистский подход. Еще раз про управление скролом в window Закрепление полей grid при прокрутке |
|
![]() |
#9 |
Участник
|
Цитата:
но в качестве спортивной разминки - почему бы и нет? https://coub.com/view/1ione Последний раз редактировалось mazzy; 15.03.2021 в 09:38. |
|
![]() |
#10 |
Мрачный тип
|
S.Kuskov, спасибо за ссылки, но там работа идет с абсолютной позицией скроллирования внутри контрола и тут mazzy будет прав - при стороннем изменении данных восстановление абсолютной позиции скроллирования после обновления данных на grid может дать совершенно кривой и дикий результат..
Я потому и пытаюсь разобраться - есть/нет возможность определения позиции текущего выделения на grid именно среди видимых строк. Если найдется таковая - задача решаема (если после обновления и восстановления выделения позиция среди видимых у выделения больше, чем до обновления - скроллируем grid на определенное кол-во шагов вниз) . Если нет - ладно, заказчик и так доволен будет...
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
|
За это сообщение автора поблагодарили: mazzy (2). |