Still no support for TAB when renaming?

MHoefler · Post by **MHoefler** » 22 Sep 2007 15:45

Hi!

The latest version 6.30.0021 still doesn't seem to support the TAB key functionality in rename mode.

Could you please add this feature (maybe with an option to enable/disable it for the very unlikely case that somebody doesn't like it)?

This is so easy to implement and it helps so much! For now, I'll use an AutoHotKey script, but I'd prefer if XYplorer would support this natively.

Thanks,
Martin

Post by **j_c_hallgren** » 22 Sep 2007 17:03

Since this was discussed before in another thread in Bug Reports, I'll put a link to that here for reference:
http://www.xyplorer.com/xyfc/viewtopic.php?p=15319
I know that Don is sometimes quite speedy for some things, but then other items are given a lower priority and take more time...

MHoefler · Post by **MHoefler** » 23 Sep 2007 11:11

I just hope it will be the "Tab" and "Shift-Tab" keys for navigating up and down in rename mode. This is the standard in Vista and so it will be the standard of Windows sooner or later. And it is perfectly logical, intuitive and it doesn't interfere with the current functionality (up, down keys, etc.)

Regards,
Martin

Post by **admin** » 25 Sep 2007 11:57

MHoefler wrote:I just hope it will be the "Tab" and "Shift-Tab" keys for navigating up and down in rename mode. This is the standard in Vista and so it will be the standard of Windows sooner or later. And it is perfectly logical, intuitive and it doesn't interfere with the current functionality (up, down keys, etc.)

I like it but there's a problem. It does interfer with standard Windows functionality: Tab/Shift+Tabare are used to move the focus between controls. I'm surprised that Vista does break this age-old rule.

As I see it (and it was discussed before -- but I'm too busy now to look it up) one could use alternatively (and more intuitive, think! -- at least in Details mode) PageUp/Down for the same functionality without losing anything, right?

MHoefler · Post by **MHoefler** » 25 Sep 2007 14:44

PageUp/Down is not intuitive, because it moves the focus one page up or down. Tab/Shift-Tab IS the new standard for moving the cursor in rename mode (because Vista implements it this way). Moving the focus between controls with Tab only needs to work when not in rename mode.

Tab/Shift-Tab is very intuitive and will be the standard. So I'd prefer to have it the same way as Vista explorer handles it (everything else would be confusing). Please at least add an option to use Tab/Shift-Tab for renaming!

Thanks,
Martin

Post by **j_c_hallgren** » 25 Sep 2007 15:26

MHoefler wrote:Tab/Shift-Tab IS the new standard for moving the cursor in rename mode (because Vista implements it this way). Moving the focus between controls with Tab only needs to work when not in rename mode.

Just because Vista does it that way doesn't automatically make it the best way!

There are plenty of us who are on older OS's that don't behave this way...

However, having said that, given that this new behavior is only while in rename mode, and thus other keys also work slightly differently than they do when in "normal" mode, having Tab do this shouldn't be that much of an issue, as when not in rename, Tab would still move focus as it does now.

Post by **TheQwerty** » 25 Sep 2007 18:03

This all brings up another place where Tab doesn't function as expected.

The standard in XP for any list boxes is that when the auto-complete list part of the control is displayed Tab/Shift+Tab function as down/up. Then you can use Escape to close the list followed by Tab/Shift+Tab to focus the next/previous control.

In XYplorer I've only found the "Go To..." and "Go To From here" dialogs doing this nearly correct. They seem to be fine if the list shows up below the edit field, but not when it appears above Tab acts differently.

I find myself missing this one quite often.

Post by **admin** » 25 Sep 2007 18:21

TheQwerty wrote:The standard in XP for any list boxes is that when the auto-complete list part of the control is displayed Tab/Shift+Tab function as down/up. Then you can use Escape to close the list followed by Tab/Shift+Tab to focus the next/previous control.

There's nothing I can do about it.

jacky · Post by **jacky** » 25 Sep 2007 18:23

j_c_hallgren wrote:However, having said that, given that this new behavior is only while in rename mode, and thus other keys also work slightly differently than they do when in "normal" mode, having Tab do this shouldn't be that much of an issue, as when not in rename, Tab would still move focus as it does now.

Not to mention that using Tab while on Rename Mode to switch focus might not really be an expected behavior. And i believe it is "disabled" in Explorer... so it might be a good implementation after all....

Post by **admin** » 25 Sep 2007 18:29

jacky wrote:
j_c_hallgren wrote:However, having said that, given that this new behavior is only while in rename mode, and thus other keys also work slightly differently than they do when in "normal" mode, having Tab do this shouldn't be that much of an issue, as when not in rename, Tab would still move focus as it does now.
Not to mention that using Tab while on Rename Mode to switch focus might not really be an expected behavior. And i believe it is "disabled" in Explorer... so it might be a good implementation after all....

Interesting indeed!

To end this thread: Ok, I'll try to implement it. But there are other things on the road map that come first.

Post by **TheQwerty** » 25 Sep 2007 18:33

admin wrote:
TheQwerty wrote:The standard in XP for any list boxes is that when the auto-complete list part of the control is displayed Tab/Shift+Tab function as down/up. Then you can use Escape to close the list followed by Tab/Shift+Tab to focus the next/previous control.
There's nothing I can do about it.

But why does it somewhat work with the Go To dialogs then?

Post by **admin** » 25 Sep 2007 18:54

TheQwerty wrote:
admin wrote:
TheQwerty wrote:The standard in XP for any list boxes is that when the auto-complete list part of the control is displayed Tab/Shift+Tab function as down/up. Then you can use Escape to close the list followed by Tab/Shift+Tab to focus the next/previous control.
There's nothing I can do about it.
But why does it somewhat work with the Go To dialogs then?

Hm. It does not work at all here! What is "somewhat"? There are three possible lists popping up depending on your settings and action:
MRU (provided by combobox internally)
Auto-complete MRU (colored)
Auto-complete paths (provided from Shell)

Which one works somewhat?

Post by **TheQwerty** » 25 Sep 2007 19:02

admin wrote:
TheQwerty wrote:
admin wrote:
TheQwerty wrote:The standard in XP for any list boxes is that when the auto-complete list part of the control is displayed Tab/Shift+Tab function as down/up. Then you can use Escape to close the list followed by Tab/Shift+Tab to focus the next/previous control.
There's nothing I can do about it.
But why does it somewhat work with the Go To dialogs then?
Hm. It does not work at all here! What is "somewhat"? There are three possible lists popping up depending on your settings and action:
MRU (provided by combobox internally)
Auto-complete MRU (colored)
Auto-complete paths (provided from Shell)

Which one works somewhat?

Guess that explains it then, as it's the path Auto-complete, so the shell control works properly, but only when the list is below the edit field.

Not sure why the shell screws it up though when the list appears above instead.

Post by **admin** » 25 Sep 2007 19:50

TheQwerty wrote:... the shell control works properly, but only when the list is below the edit field.

Not sure why the shell screws it up though when the list appears above instead.

Selecting the next entry with tab key? Never works here.

Post by **TheQwerty** » 25 Sep 2007 20:06

admin wrote:
TheQwerty wrote:... the shell control works properly, but only when the list is below the edit field.

Not sure why the shell screws it up though when the list appears above instead.
Selecting the next entry with tab key? Never works here.

Yeah, my AHK script lied and was still running even though the icon wasn't in the tray anymore.

And it just so happens that the edit fields on those two dialogs are both named Edit1, which is the same as the address bar (which the script was originally written for).

Which also explains the odd behavior when the list is above the edit field as I haven't taken the time to adapt it to watch for the list there as well as below.

So you're right it doesn't work anywhere, unfortunately.

At least it puts something in the Windows Explorer pros column