[TC 11.03] Pressing Windows key in Change drive combo box changes current folder

[white]

• Make sure TC's left and right panel show the contents of different folders on the same drive.
• Press Alt+F1, or Alt+F2 to open the drive combo box for left or right panel.
• Press the Windows key.

Both panels now show the same folder.

[Horst.Epp]

Confirmed

[petermad]

Confirmed - tested on Windows 7 - both 32bit and 64bit TC

[Usher]

Not confirmed in Windows XP for 32-bit TC. Pressing Win key properly opens Start Menu and passes focus to it.

[white]

Not confirmed in Windows XP for 32-bit TC. Pressing Win key properly opens Start Menu and passes focus to it.

Maybe you misunderstood the bug report. My report doesn't say the Windows Start Menu isn't opened. That does happen. But when that happens, the current folder of one of TC's file panels changes.

[petermad]

I can confirm the bug under WIndows XP 32bit too - When Alt+F1 is pressed and then the Win key, the left panel is set to the same folder as the right panel - and if Alt+F2 is pressed and then Win, the right panel is is set to the same folder as the left panel.

[Usher]

It may depend on plugins installed in TC or on Windows taskbar position and size. I have the taskbar on the left side in both Windows XP 32-bit and Windows 7 64-bit and in both cases Start Menu is called properly, with no sude effects in TC.

[petermad]

2Usher
I can reproduce the bug on Window XP 32bit with a fresh wincmd.ini file (no plugins) and with Windows Taskbar on the left side of the screen.

Are you sure you are on the same drive in left and right panel when you test and that the two panels shows different folders before you press the Win key - that is a prerequisite. And again - we are not saying that the Start Menu is not opened, just that it has this side effect in TC.

[ghisler(Author)]

Currently TC reacts to the press of a key in the drive combobox by changing to the drive under the cursor. When the drive is the same and you press e.g. Enter on it, TC changes to the path in the other panel. Changing items via cursor keys, pageup/pagedown, and home/end does not close the combobox, but pressing Enter or typing the drive letter/connection number does close the list and change drives. This code was written at a time when the Windows key didn't exist, so it doesn't get any special treatment. I will catch it. I found two other cases where this happens, one which I could fix and one which I could not:
1. Hold down Alt, press and release F1 (combobox opens), then press and release Tab. Can be avoided by checking whether Tab is pressed.
2. Press and release Alt+F1, then press Ctrl+Shift+ESC -> cannot be prevented, ESC is not pressed when I get the notification.
Maybe you can find any others? You don't need to report any involving the Windows key or Tab key (or both), that's already covered.

[white]

1. Hold down Alt, press and release F1 (combobox opens), then press and release Tab. Can be avoided by checking whether Tab is pressed.
2. Press and release Alt+F1, then press Ctrl+Shift+ESC -> cannot be prevented, ESC is not pressed when I get the notification.
Maybe you can find any others? You don't need to report any involving the Windows key or Tab key (or both), that's already covered.

Why not check whether Enter or drive letter/connection number was pressed (optional in combination with Shift) and only change drives when that is the case or when a mouse click was used?

Other problematic keys combos:

• F1
  Opens help and changes drive.
• Ctrl+Esc
  Opens Windows Start menu and changes drive.

I am not sure if these double actions should happen:

• Alt+Enter
  Performs Alt+Enter in file panel and changes drive.
• Ctrl+L
  Performs Ctrl+L in file panel and changes to drive L: (make sure drive L: exists).
• Ctrl+P
  Performs Ctrl+P in file panel and changes to drive P: (make sure drive P: exists) .

[ghisler(Author)]

Why not check whether Enter or drive letter/connection number was pressed

Because the mouse click and finger tap in touch mode must also be handled. I don't want to break functionality for a rare problem.

[white]

Because the mouse click and finger tap in touch mode must also be handled.

Of course.

I don't want to break functionality for a rare problem.

Is, for example, pressing F1 while the focus is on the drive combo box really such a rare problem?

I understand that this is very old code and there is a risk of introducing bugs, but it seems to be the right way to implement it, rather than implementing exceptions that do not fix all cases.

[JOUBE]

I don't want to break functionality for a rare problem.

... there is a risk of introducing bugs ...

There have been a number of problems in version 11 that are based on changes made at the request of users, and that requests are based on rare problems. (The relevant threats should be known, right? If not, please look for them yourself) These changes are now being removed at great expense...

This is pointless and annoying because side effects occur.

I agree with ghisler(author): don't want to break functionality for a rare problem.

Joube

[siealex]

Confirmed on Windows 11 64-bit, TC 32-bit.