Thanks
@mouser.
I am glad you have addressed this.
My apologies - I had always put up with this slightly annoying ergonomic behaviour in CHS, supposing it to be a CHS "foible" that you would have known all about and would have fixed if you had thought it was a problem, and so I never thought to mention it, but just worked around it.
I guess the lesson there is, don't make assumptions...
EDIT: Just some quick feedback. I confirm that, now, after deleting a clip (a row in the
Grid pane), the selector rests
one clip forwards - i.e., on the
next clip down
- which is probably what one would intuitively expect to happen.If the clip being deleted is the last (bottom-most) clip in the
Grid, then, after deletion, the selector rests on the
immediately preceding clip - which again is probably what one would intuitively expect to happen.
(In both cases, the
context is when the
Grid is currently sorted in
Modified date order - which is what I usually have it in. I have not yet tested it in the contexts of differently-ordered states.)
NB: As an observation, I would point out that this behaviour is
not what seems to have been requested in the OP, where the expectation there seems to be that, after
clip 40 in a list of 100 was deleted, the selector would be positioned on
clip 39,
one clip back (i.e., on the preceding clip, not the following clip), after the deletion.
I would thus consider this OP request to be incorrect - ergonomically counter-intuitive - and that you have fixed it to work in a more ideal ergonomically intuitive manner that would make sense in the context where you were (say) deleting clips successively, one by one, in the
Grid. That is, you would want the selector to rest on each one to be deleted in turn -
downwards - rather than skipping back to the penultimate one selected but not deleted. Again, the context of the sort order might be relevant here. Quite tricky really.
