I have a filter-field ("realtime, local, both") in one of my visible toolbars.
It seems to capture just about all hotkeys (including Ctrl-E, Ctrl-F etc) when it is focused, so I can't seem to change
focus back to the file/folder-list by using only the keyboard.
I tried assigning a new hotkey to "SET FOCUS=SOURCE" (not system-wide).
However, neither that hotkey nor the others seem to work while the field is focused.
There are only a few fields that won't do that, since edit controls in Windows respond to hotkeys and we can't predict what all of them are or will be in the future and in different langauges (and we need to explicitly re-route any we don't want the edit control to swallow up).
e.g. Ctrl-a will select-all in an edit control, including the filter control, which some people use a lot.
[quote="leo"]There are only a few fields that won't do that, since edit controls in Windows respond to hotkeys and we can't predict what all of them are or will be in the future and in different langauges (and we need to explicitly re-route any we don't want the edit control to swallow up).
e.g. Ctrl-a will select-all in an edit control, including the filter control, which some people use a lot.[/quote]
Obviously I would assume Ctrl-A and regular edit shortcuts would be captured as it actually uses those itself.
However, keys like F8, Ctrl-F3 (which were my new hotkey, because F3 focuses the filter field), Ctrl-F, and so on shouldn't.
Instead of simply rerouting x-keys, wouldn't it be easier to have it check if the keypress is on the defined hotkeys list, and if
it is, remove it and send it upwards (iow, posting it to the lister's main message queue).
My problem isn't with ctrl-a, and I don't get how that became an issue in the first place.
Whether it is DO or a windows hotkey doesn't really matter. What matters is that the filter field shouldn't capture
every single hotkey under the sun (or moon if you like)..which was the reason for what I suggested.
The problem is (as Leo has said) that the keys the field itself "needs" aren't defined anywhere. We don't know if they will change (e.g. because Microsoft add features in the future, or maybe they're different in other languages). We have no way of knowing if the edit field wants to consume a particular key or not.
Well, it is unlikely to change for a decade or two..especially for your use of the field.
..and yes you do, by knowing which keys are expected to work for that kind of control just about everywhere.
Most of the keys that are in use for a combobox (incl its edit-field), has been in use for decades.
ctrl-x,v, and c are some of, if not the most, the most recent keys that kind of control is expected to support.
..and even those have been in use for that purpose for at least a decade or two.
But well, I won't argue..although this makes the field stick out as a sore thumb because you can focus it, but you
can't focus something else afterwards..using a keyboard.
That actually worked...sort of. It seems to be executing two different
operations for the same keypress.
It swaps destination/source, then focuses the new source.
I have "use tab key to switch source/destination in dual display listers" enabled, so using
tab to switch between source/destination is normal.
When switching focus from an unrelated control I would've expected it to simply
return focus to the current source.
Initially, the reason I got a bit frustrated with exiting the filter control was that
single-clicking the source toolbar didn't return the focus, but instead made the
path editable, while doing the same on the destination toolbar switched
source/destination AND the filter control remained active (the latter seems useful).