DonationCoder.com Software > Clipboard Help+Spell

When you delete a clip, the scroll bar goes all the way down losign focus

(1/2) > >>

Chessnia:
After 24 hours operation, I felt I had too many clips on my board, so I went ahead and deleted a few.
What I'm noticing is that, say I have 100 clips. I move a long the list to, say, the 40th one, then I deleted it. The program does it but instead of keeping the focus (with the highlighted bar) on the 39th (which is the last one I reviewed) it scrolls all the way down to my last clip. Very annoying if you're trying to selectively delete some of them.
Is there a way to avoid this?

mouser:
You're right, that's annoying behavior, and it happens here too. I will fix.

Chessnia:
 :up: Thanks Mouser!

mouser:
That was more difficult than I expected.  Can you let me know how this beta version performs and if you observe any oddities:


* https://www.donationcoder.com/Software/Mouser/clipboardhelpandspell/downloads/beta/ClipboardHelpAndSpellSetup.exe
* https://www.donationcoder.com/Software/Mouser/clipboardhelpandspell/downloads/beta/ClipboardHelpAndSpellPortable.zip

IainB:
Thanks @mouser.    :Thmbsup:
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.

Navigation

[0] Message Index

[#] Next page