Игрища с позиционированием выделенной записи среди видимых строк grid'а

[TasmanianDevil]

Коллеги , может кто занимался подобным и сможет подсказать что дельное ...

Ситуация - есть grid с определенной видимой выделенной строкой, на источнике данных которого запускается обновление набора данных через research() и восстановление выделенной позиции через FindValue()/FindRecord().

В случаях, когда перед таким обновлением и восстановлением выделенной позиции :
а) выделенная позиция имела, скажем так, порядковый номер в выводимом наборе данных, не превышающий кол-во видимых строк в grid
б,) выделенная позиция имела порядковый номер в выводимом наборе данных, превышающий кол-во видимых строк в grid, но среди видимых строк grid'а стояла на последнем месте
то после обновления состояние выделения в grid и место выделенной позиции среди видимых строк grid'а не меняется.

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

Можно ли как-то перед таким обновлением считать у выделенной позиции ее текущее положение среди видимых на гриде строк и после обновления, если положение изменилось, вернуть его в первоначальное состояние (доскроллировать grid на нужное кол-во строк вниз) ?

У источника данных все "позиционные" методы касаются именно позиции выделения в наборе данных и к позиции среди видимых строк на grid'е не имеет отношения, на методах grid'а тоже ничего нарыть не смог и в поиске по форуму не удалось ничего нарыть

[mazzy]

У research параметр есть retainPosision
по умолчанию false

НО!
сама постановка - восстанавливать позицию мне кажется чертовски запоутывающей пользователя.
пользователю скорее нужно "остаться на той же самой записи, но возможно в другой позиции",
а не в "той же самой позиции, но возможно на другой записи"

насколько я помню, research(true) оставит курсор как раз на записи с тем же самым recId.
но это не точно

в любом случае, мне кажется, что НЕ нужно привязываться ни к позиции в курсоре, ни тем более к позиции в гриде.

[TasmanianDevil]

Цитата:

Сообщение от mazzy

а не в "той же самой позиции, но возможно на другой записи"

А этого никому и не надо.
Надо именно на той же выделенной записи и чтобы эта выделенная запись не "прыгала" по гриду в части своей позиции среди видимых после обновления.

Цитата:

Сообщение от mazzy

сама постановка - восстанавливать позицию мне кажется чертовски запоутывающей пользователя.

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

Возникает данный вопрос при свертке/развертке узловой записи - хотелось бы после обновления набора данных, связанного с отрисовкой добавляемых/ скрываемых подчиненных позиций, лежащих ниже выделенного узла, чтобы сам узел не менял своего положения среди видимых строк грида (см.. вложение)

Конечно же, даже сам оригинальный FromTreeControl грешен всяким в части прыжков выделенной позиции среди видимых элементов(при развертывании приыгает вверх, при свертке - вниз), но хотелось добиться более "спокойного" поведения

[Logger]

Насколько я помню, retainPosision не гарантирует что это будет та же запись. Если после выполнения запроса изменилась выборка то запись может быть другой.

Если нужно гарантировать что та же запись будет, то я делал в 2009-й некий финт.
Выставлял сортировку по какому-то уникальному полю (RecId или другой ключ)
Ставил нужное значение в element.args().lookupField и element.args().lookupValue - по уникальному полю для которого поставили сортировку.
Делал research

Позиционирование работало быстро.
Дальше можно вернуть оригинальные значения у измененных параметров.
В 2012-й можно попробовать поиграть с lookupRecord() - я сам не пробовал.

[mazzy]

Цитата:

Сообщение от TasmanianDevil

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

Возникает данный вопрос при свертке/развертке узловой записи - хотелось бы после обновления набора данных, связанного с отрисовкой добавляемых/ скрываемых подчиненных позиций, лежащих ниже выделенного узла, чтобы сам узел не менял своего положения среди видимых строк грида (см.. вложение)

закат солнца вручную
поэтому и не особо любим лично мной.

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

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

[TasmanianDevil]

Цитата:

Сообщение от mazzy

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

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

Цитата:

Сообщение от mazzy

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

Хорошо, давайте на пальцах ...
Допустим , что есть для воображаемого набора воображаемый 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

[mazzy]

Цитата:

Сообщение от TasmanianDevil

Хорошо, давайте на пальцах ...
...
Что получается при вызове research()/FindValue() ?

не-не-не.
пока в рассматриваемом случае не будет вводной "другая аксапта изменяет набор данных" рассматривать бессмысленно.

промоделируйте на пальцах что должно происходить, если набор изменился. куда и как нужно позиционировать и как сохранять позицию.

если поведение измененного и неизмененного наборов будет отличаться, то зачем это нужно? ведь для пользователь не знает об изменениях и для пользователя все равно позиция будет иногда прыгать.

[S.Kuskov]

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

Нет, не то чтобы я ратовал за подобные извращения над пользовательским интерфейсом.
Да, здесь больше спортивный интерес и чисто программистский подход.

Еще раз про управление скролом в window
Закрепление полей grid при прокрутке

[mazzy]

Цитата:

Сообщение от S.Kuskov

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

я не уверен, что такое предположение вернет в конструктивное русло - делать контрол только для статического набора в ERP-системе... м...

но в качестве спортивной разминки - почему бы и нет?
https://coub.com/view/1ione

[TasmanianDevil]

S.Kuskov, спасибо за ссылки, но там работа идет с абсолютной позицией скроллирования внутри контрола и тут mazzy будет прав - при стороннем изменении данных восстановление абсолютной позиции скроллирования после обновления данных на grid может дать совершенно кривой и дикий результат..
Я потому и пытаюсь разобраться - есть/нет возможность определения позиции текущего выделения на grid именно среди видимых строк. Если найдется таковая - задача решаема (если после обновления и восстановления выделения позиция среди видимых у выделения больше, чем до обновления - скроллируем grid на определенное кол-во шагов вниз) . Если нет - ладно, заказчик и так доволен будет...