Color setting dialog is broken if Configuration is opened too fast.

[miroslav.vrlik]

If Misc tab of Configuration window is selected too fast, dropdown menu Others in Colors tab does not react to selecting its items.

This could be reproduced manually, but I found reliable way to reproduce it using AutoHotKey, which simulates fast sequence of user actions.

Steps:

0. In AutoHotKey2, create and load hot key Alt+F1 as indicated below.
1. In Total Commander, press that Alt+F1 and Configuration window will open.
2. Switch to Color tab.
3. Start changing items in dropdown menu Others. The rest of the UI (image in Example frame, color picker) does not change to reflect item selected in Others dropdown.

Example of failure:
Item "Differences - binary mode (selected)" is selected from dropdown menu, but its color picker remains disabled and all the 6 color pickers above it, as well as initial example image are still visible.

Code: Select all

#HotIf WinActive("ahk_class TTOTAL_CMD")

!F1::	;Tools > Options
{
	Send("{F10}{Right 5}{Enter 2}{End}") ; Configuration > Options > Misc. (section)
	Send("{Tab 8}") ; Hotkey dropdown menu
}

#HotIf

[ghisler(Author)]

I can reproduce it, but only with a script, so it should not affect users.

To avoid the problem, either open the misc page with command
cm_Confirmation
or put a short sleep command in your script:

Code: Select all

#HotIf WinActive("ahk_class TTOTAL_CMD")

!F1::	;Tools > Options
{
	Send("{F10}{Right 5}{Enter 2}") ; Configuration > Options
	Sleep 100;
	Send("{End}"); Misc. (section)
	Send("{Tab 8}") ; Hotkey dropdown menu
}

#HotIf

[miroslav.vrlik]

OK, thank you for acknowledging, at least it is now confirmed there is such an issue.

I found that the problem is in leaving section list using Tab key, not in switching the section.
WORKAROUND: Leave the section list using accelerator key in one of labels.
________

Details:

After I created Total Commander keyboard mapping:

Code: Select all

Ctrl+OEM_, = cm_Confirmation  ; (Ctrl+comma opens Configuration directly in "Misc." section)

...then the same problem is still present. The only way to normal behavior is to insert delay of 1500 ms before using Tab key to move focus away from the section list on the left side of Configuration window:

Code: Select all

        Send("^,") ; Configuration dialog > section "Misc."
	Sleep(1500)  ; if this delay is not present or it is shorter, behavior of Color section is broken
	Send("{Tab 8}") ; only after delay it is possible to focus to Hotkey dropdown menu

...but leaving the section list using Alt+K accelerator (jump to Hotkey label) produces stable behavior.

Code: Select all

        Send("^,!k{Tab}") ; Configuration dialog > section "Misc." > label "Hotkey:" (Alt+K) > button with dropdown menu 

I understand this probably won't be fixed, but at least this could be understood a bit better.

[ghisler(Author)]

This should be fixed in Total Commander 11.57a RC1, please check!

12.05.26 Fixed: Opening main settings dialog via script and immediately sending Tab keys broke the Color - Others combobox, because it was assumed that the Tab key was still down (64)

[miroslav.vrlik]

On my Windows 11 PC I see a serious issue after the fix. (At least when using the AHK as in initially reported case.)
Whatever key modifier I use with AHK hotkey, the Configuration window opens flawlessly (previously reported issue appears fixed), but the hotkey modifier remains stuck:

Code: Select all

#HotIf WinActive("ahk_class TTOTAL_CMD")

#w::
^e::
+e::
!F1::
{
	Send("{F10}{Right 5}{Enter 2}{End}{Tab 8}") ; Configuration > Options > Misc. (section)
}

#HotIf

In the above example, multiple hotkeys can run the same key sequence (this is as an example to illustrate the problem)

• If I use Win+W, then Win key is sometimes stuck. So if the TCmd sends Tab keypress silently, Win+Tab task switcher is activated.

• If I use Ctrl+e, then Ctrl key is sometimes stuck. Pressing Esc to close Configuration window starts sending Ctrl+Esc, i. e. it is opening Windows Start menu.

• Similarly, upon pressing Shift+E, shift key gets stuck. Attempt to change "F4 editor" makes input box for path behave as if Shift was pressed.

• Similarly for Alt.

[Fla$her]

miroslav.vrlik
Experienced users don't use simulated keystrokes, it's too unreliable, regardless of the application.
An example from the Autorun help for comparison:

Code: Select all

LoadLibrary Plugins\Autorun_Tweaks.dll
LoadLibrary Plugins\Autorun_Runtime.dll
#——————————————————————————————————————

# Ctrl+Alt+H — opening the "Misc." settings page and the hotkey menu in it
SetHotkeyAction /K:C /K:A /H:H ExpandHotkeyMenu

Func ExpandHotkeyMenu
   PostMessage(AUTORUN_TCHANDLE, 1075, 495)
   While Not WinGetState(4, WinFind(0, 'TDLGCONFIGALL'))
      Sleep 40
   Wend
   If AUTORUN_TCARCH = 32 Then
      SendMessage(WinFind(WinFind(0, 'TDLGCONFIGALL'), 'TBitBtn'), 0xF5)
   Else
      SendMessage(WinFind(WinFind(WinFind(WinFind(WinFind(0, 'TDLGCONFIGALL'), _
      'Window', 1), 'Window'), 'Button', 1), 'Button'), 0xF5)
   EndIf
EndFunc

[ghisler(Author)]

2miroslav.vrlik
I'm not messing with the modifier keys like Ctrl or Win, all I do is send additional tab key up, down and up. Therefore the state of the win key is the responsibility of your script, you must make sure that the state changes to not pressed at the end of your script.

Btw, I tried setting the "TabStop" option of the tab control (TNotebook) to False, but it didn't work. So the current solution is the best I can offer.

[miroslav.vrlik]

Yes, I know that you are not messing with modifiers. I view this for long time already as a weak part of Windows platform. Modifiers can get stuck even during work of standard users https://superuser.com/q/956049/287473 and often even cannot get properly programmatically cleared. (Sending "key up" for all modifiers does nothing.) Currently I see reliable cleaning as physically pressing the "stuck" key again or hitting of Ctrl+Alt+Del (it cleans them all).

Based on this recent case I believe the cause of the mess is the condition of SendKeys routines (an umbrella name for bunch of them) running in parallel. SendKeys from TotalCmd is invoked while SendKeys from AHK is still running. That probably interferes with Windows governance of key modifiers and randomly leaves a mess. This is good to know for me, because now I understand how to handle everything better in AHK in case if the active application also attempts to send some keys. I need to stop sending anything before the other app wants to do sending, then I can potentially resume.
Thank you for the effort.

P.S. My additional solution is to ensure that no modifier keys are held down when you send the two tabs. At the beginning of my script which is launched using Ctrl+key, I placed a call KeyWait("Ctrl").

[Fla$her]

2miroslav.vrlik
If I were you, I would use $ in front of the hotkey operators (or #UserHook on top). Try:

Code: Select all

#If WinActive("ahk_class TTOTAL_CMD")

$^e Up::
{
   PostMessage(1075, 495, 0,, A)
   WinWait("ahk_class TDLGCONFIGALL")
   WinActivate
   SendInput("{Control UP}{Tab 8} ")
}

#If

Code: Select all

#UserHook
#SingleInstance force
Hotkey "IfWinActive", "ahk_class TTOTAL_CMD"
Hotkey "#w Up", "Misc_HotKeyMenu" 
Hotkey "^e Up", "Misc_HotKeyMenu"
Hotkey "+e Up", "Misc_HotKeyMenu"
Hotkey "!F1 Up", "Misc_HotKeyMenu"

Misc_HotKeyMenu() {
   PostMessage(1075, 495, 0,, A)
   WinWait("ahk_class TDLGCONFIGALL")
   WinActivate
   KeyWait "Control"
   KeyWait "Alt"
   KeyWait "Shift"
   KeyWait "LWin"
   KeyWait "RWin"
   SendInput("{Tab 8} ")
}

[ghisler(Author)]

I think I found a solution now without sendkeys in Total Commander 11.58 RC1, please check!
(Note that the name has been changed because WinGet thinks that 11.57a is older than 11.57).

[miroslav.vrlik]

I believe this one is fine. I tested it many times and it seems to work without initially discussed issues, especially in "Color" section.

And... maybe it is a subjective feeling (and maybe also other things were changed), but I would say that in version 11.58 RC1, the Configuration window opens noticeably faster than before. From many tests before, I remember delays up to 0.7 seconds on almost every opening, and now the window is displayed immediately in 50 of 50 test runs. Impressive. Thank you.

[ghisler(Author)]

I believe this one is fine. I tested it many times and it seems to work without initially discussed issues, especially in "Color" section.

Great, thanks!

And... maybe it is a subjective feeling (and maybe also other things were changed), but I would say that in version 11.58 RC1, the Configuration window opens noticeably faster than before. From many tests before, I remember delays up to 0.7 seconds on almost every opening, and now the window is displayed immediately in 50 of 50 test runs. Impressive. Thank you.

I don't see any speed difference when using the 64-bit versions.
Opening the 32-bit settings in 64-bit Windows is considerably slower, probably because of the 32->64 translation layer having to create a LOT of window handles. This slowness isn't there on 32-bit Windows.

Moderator message from: ghisler(Author) » 2026-05-31, 07:51 UTC

Moved to fixed bugs

[white]

This slowness isn't there on 32-bit Windows.

Typo ? 32-bit -> 64-bit ?

[ghisler(Author)]

No, what i wanted to say is that the settings dialog of 32-bit Total Commander only opens slowly on 64-bit Windows, due to the translation layer. It is not opening slowly on 32-bit Windows. There it opens as quickly as the settings of the 64-bit version on 64-bit Windows.

[white]

Got it. I read it wrong.