XYplorer Beta Club

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

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...

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

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?

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

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.

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.

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.

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....

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.

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?

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?

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.

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.

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