alt+tab twice for full switching

[strange-weather]

I have to press alt+tab twice for full switching. The problem arise every time when I use alt+tab, after a short period of time since I've been working with any program.

It might also be useful to know, If a window is minimized, it always restores it, but doesn't give it focus. This keeps the window out of the foreground.

On one of the previous versions the same thing happened, but not as often as now.

[cracklejoy]

The last version that seems to work correctly and avoids this type of behavior was v0.46 according to my testing...

[sl9dge]

I have the exact same issue, also, the alt tab is sometimes pretty slow (it got realllly slow a few minutes ago during Fortnite's update, this might have something to do with drive writing)
I uninstall for now, but I'm most definitely waiting for this to be fixed, alongside this other glitch :
#79

[Milincho]

Same here. The program is unusable if is this unreliable.

[strange-weather]

The last version that seems to work correctly and avoids this type of behavior was v0.46 according to my testing...

YES! Just checked and this version v0.46 works really well !!!

[hdlx]

I can't reproduce the issue, but since you're writing that 0.47 is the first version with regression, I made a new release to test an hypothesis.
@strange-weather, @Milincho can you please try pre-release v0.57. In the settings, set "Debug only: disable icon focus" to "true", and tell me whether it fixes the issue or not.
Thanks

[kb9alpp]

The core issue was still present when I tried pre-release v0.57.

Since Paul had no luck reproducing, I compared working v46 to latest v0.57 and put a summary below. I had a hunch that a PR addressing this regression would be probably welcome.

Details

Findings

The diff output showed many changes, mostly in focus/minimized window logic (suspected bug areas).

Here's a breakdown by file/category—focusing on what could cause double-press (e.g., async races or focus failures):

App.c (Major Changes—Core of the Issue):

• Async Apply Still Present: #define ASYNC_APPLY is untouched, so ApplyWithTimeout (with worker threads and 1-sec timeouts) is still used. This is our top suspect—timeouts can abort partial applies on first press, requiring a second try (as we discussed).
• UI/Focus Refactoring: UIASetFocus function simplified (removed IUIAutomation* param, now initializes COM inside). Added SetFocus calls in ApplySwitchApp for regular apps. New focus windows array for icon focus (via MSG_FOCUS). This might cause UWP/elevated focus to fail faster /date, leading to retries.
• Key/Message Handling (KbProc): Completely refactored—added Vim/arrow navigation, invert logic (MSG_INVERT), and separate MSG_RESTORE_KEY (no longer inline RestoreKey).
• RestoreKey now has explicit retries (usleep(1000) between sends) and checks for stuck keys (e.g., VK_RCONTROL). This could delay apply, making async "hang" on first press.

Environment

AltAppSwitcher versions: v46 (working) vs. v0.57 (latest broken)
Setup to reproduce: Various (win10) apps reproduce on (press) Alt + Tab (1st press doesn't work, 2nd switches) or the [different] key combo you use.

AI was used in my work.

[hdlx]

Hi. If you try pre-release, can you confirm you set the setting "Debug only: disable icon focus" to "true", as mentioned in my previous post?

Also, since 0.47 shows the issue according to other users in the post, no need to search for regression from 0.46 to 0.57, simply look at the commits between 0.46 and 0.47.

By the way, the "top suspect", ASYNC_APPLY, is present since 0.36. Didn't check the other suspects but again, if 0.47 does not work but 0.46 does, there is only very few suspect, one being the feature I disabled through "Debug only: disable icon focus" option in 0.57.

[kb9alpp]

Thanks for the quick reply and the detailed guidance. Yep the "Debug only: disable icon focus" was set to "true" in the config for my pre-release test.

[kb9alpp]

Per your suggestion, I diffed v0.46-v0.47 and gave Grok Code Fast 1 another crack at it. Summary below.

Details

Key Diff Findings (v0.46 Working → v0.47 Broken)

Focused on Sources/AltAppSwitcher/App.c (core switching file). No major changes to ASYNC_APPLY or UIAutomation itself—icon focus stands out as the regression. ~30-40 new/additional lines in v0.47, all related to creating and focusing child windows per app/icon.

• Icon Focus Feature Added (Suspected Cause):

  • New message define: + #define MSG_FOCUS (WM_USER + 1) (for triggering focus on selection).

  • New child window class: + static const char FOCUS_CLASS_NAME[] = "AASFocus"; with registration and FocusWindowProc handler.

  • Child windows creation: In MainWindowProc (renamed from WindowProc), WM_LBUTTONDOWN now creates a focusWindows[MAX_WIN_GROUPS] array of child windows (one per app group) positioned under icons:

    + static const char FOCUS_CLASS_NAME[] = "AASFocus";  // New class for focus windows
    + static HWND focusWindows[MAX_WIN_GROUPS];  // New array in MainWindowProc
    + for (int i = 0; i < appData->_WinGroups._Size; i++) {
    +     focusWindows[i] = CreateWindowEx(0, FOCUS_CLASS_NAME, NULL,
    +         WS_CHILD /* | WS_VISIBLE */, x, pad, iconContainerSize, iconContainerSize,
    +         hwnd, NULL, appData->_Instance, NULL);  // Creates child windows on UI show
    + }

    Potential race: These child windows might conflict with main window focus during async apply, especially for UWP where UIAutomation timing is key.

  • Focus triggering: On app selection changes (MSG_NEXT_APP/MSG_PREV_APP), sends + SendNotifyMessage(_AppData._MainWin, MSG_FOCUS, 0,0 );.

  • Focus application: New MSG_FOCUS case initializes UIAutomation and sets focus to the child window:

    + case MSG_FOCUS:
    + {
    +     CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
    +     IUIAutomation* UIA = NULL;
    +     DWORD res = CoCreateInstance(&CLSID_CUIAutomation, NULL, CLSCTX_INPROC_SERVER, &IID_IUIAutomation, (void**)&UIA);
    +     ASSERT(SUCCEEDED(res))
    +     UIASetFocus(focusWindows[appData->_Selection], UIA);  // Focuses child window, not target app
    +     IUIAutomation_Release(UIA);
    +     CoUninitialize();
    +     return 0;
    + }

    This could interrupt async apply on first press (focuses "invalid" child instead of actual app), requiring retry—matching the double-press bug.

• Revised Function Name (UI Logic Refactor):

  • WindowProc → MainWindowProc (and CLASS_NAME → MAIN_CLASS_NAME). Adds professionalism but no functional impact.

• Other Minor Tweaks (Likely Non-Causal):

  • IsEligibleWindow gained ignoreMinimizedWindows param for config-tied filtering.
  • Macro defines: + #define MAX_WIN_GROUPS 64u.
  • Window placement/move optimizations.

No other files showed significant diffs (e.g., Config.h: Added _DebugDisableIconFocus, as expected; Updater.c: Unchanged). The icon focus additions fit your hypothesis—they're the "new feature" and directly touch focus/selection logic, potentially racing with async apply's UIA calls.

---

What Those Code Items Specifically Do

Let's map the diff elements you mentioned to their roles:

1. New Child Window Class: static const char FOCUS_CLASS_NAME[] = "AASFocus"; with Registration and FocusWindowProc Handler
   • Role: Defines and registers a new Windows window class (class name "AASFocus") specifically for these accessibility focus elements. The FocusWindowProc is a lightweight window procedure (callback function) that handles messages for each child window (basically acknowledging standard window events like paint, destroy, etc., but doing nothing extra—it's passive). This class is registered separately from the main switcher window for clean organization.
   • User Impact: Ensures the child windows exist as valid, focusable Windows UI elements. Without this class, Windows wouldn't recognize them as proper controls, breaking keyboard/screen reader interactions. It's like defining a basic widget template—users don't see or interact directly with the class itself, but it enables the focus behavior underneath.
2. Child Windows Creation: In MainWindowProc (formerly WindowProc), WM_LBUTTONDOWN Creates focusWindows[MAX_WIN_GROUPS] Array
   • Role: When the switcher UI opens (triggered by WM_LBUTTONDOWN—mouse click to initiate the preview), this creates an array of invisible child windows (focusWindows). Each child window is sized and positioned to match an app's icon in the UI grid (one per app group, up to 64). They're styled as WS_CHILD (child of the main window), with extents matching each icon's container area (e.g., x/y position and icon size). The code calculates positions dynamically: x = pad + i * (iconContainerSize); so they align perfectly under the visible icons.
   • User Impact:
     • Makes each app's icon "selectable" via keyboard (e.g., pressing Tab cycles through them). The child window acts as a proxy for focus— when selected, Windows treats it as the active "control" in the UI.
     • Enables better interaction: For keyboard users, these windows provide hidden "anchors" so assistive tech can hone in on individual apps without guessing mouse positions. If disabled (via _DebugDisableIconFocus), it's like the icons become inert—accessible only via mouse or basic Alt+Tab keys.
     • Under the Hood: They're not visible (no WS_VISIBLE flag in creation), so users see the same UI, but programmatically, each icon now has a backing "window" that can receive focus/U IAutomations events.

In essence, these elements create a "virtual keyboard interface" layered over the icons. Without them, the switcher UI is just a pretty picture— with them, it's a navigable widget list.

How This Ties to the Double-Press Bug

This feature is likely causing the issue because:

• Focus Competition: On app selection (MSG_NEXT_APP/MSG_PREV_APP), it sends MSG_FOCUS, which uses UIASetFocus to set focus on the child window under the selected icon (via UIAutomation for accessibility). However, the core app-switching logic (async apply) relies on focusing actual app windows. If these two focus actions race or conflict (child window focus "wins" first, blocking app focus), the first Alt+Tab might apply the UI focus but fail to switch the app—hence, double-press required to retry the "real" focus.
• Timing Sensitivity for UWP/Async: As discussed, async apply uses timeouts; focusing these child windows (even briefly) could disrupt the worker thread's UIA calls, causing aborts on first try. It's a benign feature that works in isolation but clashes in the async world.
• Why Disabling Didn't Fix It in Pre-Release: Per your testing, even with _DebugDisableIconFocus = true, the double-press persisted. This suggests the toggle might not fully prevent their creation or that there's a related race in the messaging/selection logic that's enabled regardless.

[hdlx]

Thanks for the insight. The focus window logic was indeed my suspect. This is the code disabled by "Debug only: disable icon focus" in 0.57 🙁
About:
Why Disabling Didn't Fix It in Pre-Release: Per your testing, even with _DebugDisableIconFocus = true, the double-press persisted. This suggests the toggle might not fully prevent their creation or that there's a related race in the messaging/selection logic that's enabled regardless.
I can double check but I'm quite confident the option indeed prevents child window creation and the set focus message.

[hdlx]

@kb9alpp I found something related to the focus feature and indeed not fully disabled by "Debug only: disable icon focus".
Can you please give another try, with pre-release v0.58, again with "Debug only: disable icon focus" set to true ? Thanks.

[kb9alpp]

Tested new pre-releases, and both require a second press. Grok thinks there’s another trigger for the race. Summary below.

I love the vim key support from @sergiopani 🙂

Summary

Evidence (0% Speculation):

• Async Race Calls Ungated (Core Issue): Line 1406 (SetFocus(winGroup->Windows[0]);) in ApplySwitchApp and line 1496 (UIASetFocus(win);) in ApplySwitchWin trigger unconditionally during switching (ApplyWithTimeout at lines 1887, 1895, etc.). They set Windows/UIA focus on app windows (COM init at 1340, UIA set at 1348), racing with timeout-sensitive logic. Not checked by DebugDisableIconFocus.
• Gating Scope: Limited to child windows—DebugDisableIconFocus checks wrap UI creation/messaging but not async app focus functions (no checks at 1406/1496).
• Race Proof: With "_DebugDisableIconFocus = true", child windows/UI skip, but UIASetFocus/SetFocus still fire in async, clashing with COM/timing (e.g., UWP focus aborts worker threads, requiring priming retry).

Missed Spot (Global Why Priming Lingers):

Async functions ApplySwitchApp/ApplySwitchWin weren't gated—previous bug fixes fixed the debug option for UI but not the underlying Windows_LIB focus race in core switching. This leaves COM/UIA unchallenged, explaining the situation.

Suggest: Add if (!appData->Config.DebugDamageIconFocus) checks around lines 1406/1496, or remove those calls entirely for v0.46-like simplicity.

[hdlx]

Thanks for your time testing.
I'm working on a bigger refacto of the app. It's a bit hard to assert that it will help, as I have no repro on my side, but it might improve things.
Regarding LLM analysis:

• Focus related calls mentioned are not related to the "icon focus feature" introduced in 0.47.
• The call SetFocus(winGroup->Windows[0]); (1406) was not even compiled on latest 0.57/0.58 versions, due to an mistake on the preprocessor macro around it. This means its already disabled as suggested.
• The other call mentioned (l. 1496) belongs to ApplySwitchWin which is not called when alt-tabbing with default settings.