Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes

[darrenmjones]

petermad,

I no longer believe it has anything to do with the ini file.

I have tried several suggestions from Dalai including starting TC with /i=%TEMP%\test.ini or completely deleting it and also redirecting the Search sections to a read-only file. None of these made any difference to the behavior. It ALWAYS happens in 11.xx and NEVER happens in 10.52 or prior.

I have 2 computers and for me it is consistent on both computers, regardless of any ini change I have tried.

If you have a chance, could you please try my steps to see if you can also reproduce it? The bug is seen in step 5.

1) Start Total Commander
2) Alt-F7, type "a" before the dialog loads. The "a" should NOT be selected.
3) Start Search - This is the step I was missing on my second computer. I never actually executed a search, and this is required for it to fail on the 2nd pass.
4) Cancel out of the Search dialog
5) Alt-F7, type "a" before the dialog loads. This time the "a" IS auto-selected and if you continue to type it will erase the "a" and replace it with what you type.
6) Close Total Commander - this resets you back to step 1.

Thanks in advance

[JOUBE]

2) Alt-F7, type "a" before the dialog loads.

?

What kind of systems are these that is even possible (entering the "a" before the dialog starts)?

- Please enter here for both computers: Windows version, CPU, RAM, HDD/SSD type etc

- Restarted the computers every now and then while testing?

- And do not loaded any other programs and tools (e.g. in autostart) so that it is clear that it is not related to other programs.

- Is it a resources problem (GDI objects)?

[darrenmjones]

JOUBE,

Have you tried to reproduce it? Please try.

It takes approximately 0.5 seconds for the dialog to load and it's fairly easy for me to type a single character in that amount of time (usually 2-4 characters).

My typical use case is I search for something like *searchstring* and the leading asterisk and next character or 2 happen before the dialog loads and disappear because they are selected and then replaced as I continue typing. As mentioned in previous posts, it does not happen on the first search after loading TC but rather the second and subsequent searches.

This has been happening since 11.00 which was released in August, 2023. Yes I have restarted both computers many times in the last 7 months.

Computer 1: Intel i7-9700K 3.60 GHz, 96gb RAM, 1tb SSD, Windows 11 ver 23H2 build 22631.3296
Computer 2: Intel i7-8750H 2.2 GHz, 32gb RAM, 1tb SSD, Windows 11 ver 23H2 build 22631.3296

[AntonyD]

1) Start Total Commander
2) Alt-F7, type "a" before the dialog loads. The "a" should NOT be selected.

I also do NOT understand how is that even theoretically could be possible
because the real life shows that it is IMpossible.
If I will type any key - this input will go inside the COMMANDLINE! and NOT
in the not visible in this time moment dialog.

So just record the video - where and how you do that.

[AntonyD]

It takes approximately 0.5 seconds for the dialog to load

And I still do not understand - why you are NOT waiting for these 0.5 sec.? Are you `Flash`?

[JOUBE]

Have you tried to reproduce it? Please try.

For me it's almost impossible to type something so quickly after Alt+F7 that the window isn't already open. Also, I have not and will not try this with previous versions of Tc because it is not a problem for me.

If I still try to enter keys so quickly after Alt+F7 with TC11.03 that the window is not yet open, I have the following results:

- When called up Alt+F7 for the first time, nothing is swallowed, neither numbers nor a "*"
- On the second call of Alt+F7, the previously entered text is apparently completely marked, so that it is replaced by a new key entered before the window opens. In this case too, nothing is swallowed.

I hope I understood your handling correctly. So I can't reproduce the described behavior here (I will not check whether it differs from previous versions).

What comes to mind: virus scanners. keyboard driver, Hotkeys, GDI object resources.

[darrenmjones]

I've recorded 2 videos where I recorded the same sequence with versions 10.52 and 11.03.

tc1052.mp4 - https://drive.proton.me/urls/RG0528HKEM#46kK2DDMEi68
You see me execute the first search where I typed "a" before the dialog loads and it is not selected. After completing that search and Canceling, the second search I type "b" before the dialog loads and it is not selected. I'm then able to continue typing and my "b" remains at the beginning of the search string.

tc1103.mp4 - https://drive.proton.me/urls/Z0WVXE2EYW#AjOHE2cxsU1L
You see me execute the first search where I typed "a" before the dialog loads and it is not selected. After completing that search and Canceling, the second search I type "b" before the dialog loads and it IS selected. Because it is selected, when I continue typing, the "b" is replaced by the new characters that I type.

[Hacker]

I haven't tested with an older version, but I can reproduce the behavior described for 11.03.
It only happens when something is found in the first search, and the list of files is loaded for the second search. If there is nothing found in the first search, the letter entered in the second search isn't selected.

Roman

[darrenmjones]

Thank you for testing it Roman. I'm happy to know that it isn't just my 2 computers where it is reproducible.

[JOUBE]

According to your videos:

the second search I type "b" before the dialog loads and it IS selected. Because it is selected, when I continue typing, the "b" is replaced by the new characters that I type.

Is it this behavior that you mean, which I also described here?:

- On the second call of Alt+F7, the previously entered text is apparently completely marked, so that it is replaced by a new key entered before the window opens.

[Hacker]

JOUBE,

Is it this behavior that you mean, which I also described here?

No. First search for "a" and make sure some items are found. Close the search, press Alt-F7. When the search window opens, "a" from the previous search is shown and selected. I assume this is what you are talking about. However, if you manage to quickly press "b" before the search window opens, "b" is shown and selected instead of "a".

Roman

[JOUBE]

"b" is shown and selected instead of "a".

And the 'selected' is the problem *) and the difference to 10.52?

*) because it is deleted with the next input?

[petermad]

2darrenmjones

3) Start Search - This is the step I was missing on my second computer. I never actually executed a search, and this is required for it to fail on the 2nd pass

I did that in my test - and I see no difference in the behavior between TC 10.52 and 10.03. In both cases the text from a previous search is highlighted - and if I start typing before the dialog is open, then all text from the previous search is replaced by the new entry.

It only happens when something is found in the first search, and the list of files is loaded for the second search. If there is nothing found in the first search, the letter entered in the second search isn't selected.

That's it (highlighted) - and here is where there is a difference between TC 10.52 and 11.03.

The differnce could be due to this fix in TC 11.00b8:

16.06.23 Fixed: Find files: When starting a search, shorten the time during which the background of the expanded dialog box is shown in black (cannot be avoided completely) (32/64)

[Hacker]

JOUBE,

And the 'selected' is the problem *) and the difference to 10.52?
*) because it is deleted with the next input?

As I understand the OP, yes.

Roman

[JOUBE]

JOUBE,

And the 'selected' is the problem *) and the difference to 10.52?
*) because it is deleted with the next input?

As I understand the OP, yes.

Roman

So it is a good idea to forward it to ghisler(author) and wait for his comment.