Files are sorted by name, otherwise the problem doesn't show.
My problem is, after renaming a file such as ATEST.TXT to ZTEST.TXT the focus/selection bar moves to the files new position, but the border doesn't.
The result is that arrow up/down moves, inline renames etc operates on the file at ATEST.TXT's old position, not at the new position.
I've tried checking/unchecking the 'reset position after sort' (not exact wording) but it seems this doesn't apply in this situation, at least it doesn't apply on the border.
As far as I can see there isn't a way to turn that off. It's by design, so that you can use inline rename mode to rename several files in a row, pushing down-arrow between each file.
What are you doing that needs the keyboard focus to be on the renamed file, out of interest? If you just want to rename and then launch a file then you can do that since the file is still selected and the selected file (not the one with the keyboard focus outline) will be launched if you hit return.
[quote="nudel"]
What are you doing that needs the keyboard focus to be on the renamed file, out of interest? If you just want to rename and then launch a file then you can do that since the file is still selected and the selected file (not the one with the keyboard focus outline) will be launched if you hit return.[/quote]
To start explaining, I mainly use the keyboard to do things, as in my case it is faster most of the time.
It is not so much what I do, but its a bit confusing when the apparent location of the selectionbar (most visible) isn't the same as where the arrow up/down, selections, and everything else starts from.
According to this quote from the reference, the behaviour I explained is the same as if 'Reset focus entry when sorting file list' is checked, not otherwise.
Apparently this checkbox does its thing (or not) when clicking the headers (the outline stays where it was, or not), but not when triggering a sort (which a rename does when the selected sort is 'by name') any other way.
Not really sure if this is intentional differing behaviour, and eventually what option would disable this behaviour.
I can see the strong points for both behaviours, but to me it seems it should depend on that particular checkbox.
That checkbox only has an effect when the sort order is changed, not when new/modified items are re-sorted according tot he existing sort order.
You could turn off automatic sorting of new/modified items so the file doesn't move in the list at all when renamed but that's probably not what you want either.
I'd say the best thing to do is write to GPSoftware support (link in my sig) and suggest the idea to them of an additional option that moves the keyboard focus with the file that is renamed.
[quote="nudel"]That checkbox only has an effect when the sort order is changed, not when new/modified items are re-sorted according tot he existing sort order.
You could turn off automatic sorting of new/modified items so the file doesn't move in the list at all when renamed but that's probably not what you want either.
I'd say the best thing to do is write to GPSoftware support (link in my sig) and suggest the idea to them of an additional option that moves the keyboard focus with the file that is renamed.[/quote]
For me the preferable would be that selection and focus either stay where it was after a rename (the bar and focus is on the same position it was before renaming the file), or moved with the file, not both at the same time as it currently does.
I guess I'll try experimenting a bit with your suggestion, or maybe there's a way to make the border more visible.
Eventually I might just contact GPSoft to suggest it.
Thank you for taking the time to suggest some solutions for me.
Yes, or the simpler single checkbox 'Keyboard focus follow selection after rename', as that would be plenty, and wouldn't result in a lot of extra coding.
I haven't encountered this issue in any other cases than after a file rename.
I'm still somewhat new with DO, but so far it seems this is the only case it
doesn't do this already. Except ctrl+up/down, but that's intentional.
I guess it is something I after some time can learn to live with, it's just not particulary visible on my background.
The behaviour surprised me a bit as in general the item/button/etc having the visual focus is the one that receives the keyboard input, not something barely visible.
Perhaps I didn't mention it already, but I use details mode.
FWIW, it's much more visible on a lighter (or darker) background (see below). Using a mid-gray background colour is probably the worst-case scenario since the black/white dotted rectangle averages out to a very similar gray.
I would say that this is the standard way to indicate the keyboard focus (and is created by the DrawFocusRect() API) but I guess that isn't strictly true anymore since some programs use solid rectangles now, or completely different things like Explorer in Vista's background colours. Now it's just one of the standard ways.
[quote="nudel"]FWIW, it's much more visible on a lighter (or darker) background (see below). Using a mid-gray background colour is probably the worst-case scenario since the black/white dotted rectangle averages out to a very similar gray.
I would say that this is the standard way to indicate the keyboard focus (and is created by the DrawFocusRect() API) but I guess that isn't strictly true anymore since some programs use solid rectangles now, or completely different things like Explorer in Vista's background colours. Now it's just one of the standard ways. [/quote]
I know, and as you hinted, it's almost invisible with that background.
I have a tendency to use it wherever possible due to headaches of too much white backgrounds in the past (I use a lcd screen now), as this and darker is the most comfortable on my eyes.
I have made some colorchanges though, just to accomodate the outline (in most programs it wouldn't be necessary as the bar tends to be at the same position), so at least it is possible to see where it is now.
