Replace start search doesn't refocus input menu

[Indeedornot]

I have just installed the newest version of ET and was excited to try out the Replace Start Menu Search option,
however when i open it using windows button and start inputting stuff, it opens however only takes in few keystrokes, before i have to refocus it manually

I am using Everything 1.5a (with a fix applied), ET 1.0.2 and Windows 11 22H2

Example.mp4

[mateusfn98]

up

[srwi]

Unfortunately I can not reproduce the behavior. Are you using any other applications that might interfere with the window focus? There was another case where MicaForEveryone was causing problems: #308 (reply in thread)

[Indeedornot]

Apologies for not responding, wanted to wait since I've wanted to reinstall windows for some time now, because due to modifying it from time to time I could've had some program do that as you said. But now with fresh windows 11 2H22 the problem is still persisting

[Indeedornot]

This video file should better show the problem. As shown when switching into a search bar the focus seems to go to the last focused input

Film.bez.tytulu.Wykonano.za.pomoca.Clipchamp.mp4

[srwi]

Thank you for your efforts! It's probably some timing issue, although I tried it on slower machines without problems. In the end I'll have to come up with a more robust way of replacing the start menu search. I've tried my luck on another implementation a while ago but didn't really get anywhere. I'll convert this discussion into a ticket to have it properly tracked.

[morgenman]

Fresh install, facing this issue. 22H2. If I had to guess, dismissing the start menu forces the focus to return to the previous application window. Perhaps instead of explicitly dismissing the menu we could switch contexts to the toolbar window. Or just add a bit of delay.

[morgenman]

Additional note that may be related:
Everything toolbar seems to struggle to loose focus too.
If the search window is completely closed and I hit the start button, then start typing, everything behaves as expected.
If I click on a result, or click out of the search window, the search window disappears. Next time I attempt to do the same thing however, only the first character makes it through. This time, clicking outside of the search window or choosing a result does not cause the window to disappear, only to be defocused & returned to the background. While it's in the background, it fails to capture windows search indefinitely. The only way to get it to properly close & return to normal is to refocus it and hit the escape key. (Simply refocusing & clicking out of the search window persists the one character captured issue).
It should be noted that this issue does not show up if you use the escape key to close the search window. You can search, then close using escape multiple times in a row without issue.

Tl;dr: Automatic dismissal of the search window when a result is chosen or focus is lost is bugged, functionality for escape key should be replicated to the automatic close methodology.

[srwi]

Thanks for the additional information. I think the whole implementation needs to be redone at some point, so I am not sure I would be facing the same issues with the rewrite of that feature. Still, the information might be helpful then.

I opened a dedicated issue for it in #341 a while ago.