Browser - filelist - rename - incorrect cursor position

[user0]

XnViewMP 1.5.0
Windows11 (22H2), display resolution 3840x2160, dpi scale 150%

Browser - filelist - file rename
incorrect cursor position after selection is cancelled

To reproduce:
1. open Browser
2. select image
3. press F2 to rename
whole name will be selected

Issue A
4. press → once
selection will be cancelled
cursor will be positioned one character to the right after selection

cursor_position.png (3.04 KiB) Viewed 6101 times

Expected behaviour
arrows in rename mode shall work the same way as in Windows File Explorer:
cursor shall be positioned right after last character of the selection


Issue B
same issue if rename via popup dialog (in Browser/Viewer)
4. manually select few characters in the middle of the name
5. press → (or ←) once
selection will be cancelled
cursor will be positioned to the wrong place that for some reason based on the direction of selection

Expected behaviour
arrows in rename mode shall work the same way as in Windows File Explorer:
→ - cursor shall be positioned right after last character of the selection
← - cursor shall be positioned right before first character of the selection (same as in issue A)


Issue C
4. press ↑ or ↓ once
name edit mode will be cancelled
focus will shift to another file

Expected behaviour
arrows in rename mode shall work the same way as in Windows File Explorer:
↑ equals ←
↓ equals →






Related

• issues
  1.9.2 - browser - filelist - addressbar and titlebar when opening file list
  1.7.1 - browser - filelist - header highlighting issues
  - todo -
  1.9.3 - browser - filelist - no update after lossless operations
  1.9.2 - browser - filelist - misleading Folder conflict dialog when copying shortcut
  - fixed -
  1.8.0 - browser - filelist - details view - pasted file opens in new instance (1.9.0)
  1.6.5 - browser - filelist - history is purged only when Browser tab is opened (1.8.1)
  1.7.2 - browser - filelist - checkbox looks checked at win scale >100% (1.8.0)

• suggestions
  Settings - filelist - custom filter - open with - add more options
  Browser - filelist - filter - improve tags
  Browser - filelist - toolbar - improve customization
  Browser - filelist - toolbar - rework filters
  Browser - filelist - rename - incorrect cursor position (current post)
  Browser - filelist - hint - limit max length
  - done -
  Browser - filelist - Move should not Copy files (1.9.6)
  Browser - filelist - Copy should not be default action (1.9.6)
  Browser - filelist - add statusbar (1.9.0)
  Browser - filelist - details view - improve Rating, Color label appearance (1.8.1)
  Browser - filelist - context menu - unify behavior (1.8.0)

[vertigo]

Bumping this as this issues has now gone 2.5 years unresolved and without response since posted, and my post a year ago regarding it also didn't get an admin response. This seems like it should be a relatively minor fix, yet it's a major issue for actual use and is the main reason I've never really switched to using XnView, even though it would be preferable otherwise. I'd appreciate some discussion either regarding the intent to fix this or reasoning to not do so, as I'm hoping it can be done so I can use XnView more, but would really like to at least know if there's no intention of doing so, so I can figure something else out.

[xnview]

it's not better to go before dot?

[user0]

it's not better to go before dot?

nope
need to mimic exact behavior of win file explorer in basic functionality, as it is practically the standard

[xnview]

Thanks to your detailed description I can reproduce the problem.