Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
Moderators: Hacker, petermad, Stefan2, white
-
- Junior Member
- Posts: 20
- Joined: 2024-03-19, 13:30 UTC
Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
When you use Alt-F7 to Search, in version 10.52 and all prior versions of Total Commander you could start typing the search text immediately, and when the dialog appears, it would contain all keystrokes, even those you typed while the dialog was loading.
Version 11.00 introduced a bug where any keys that you type before the window appears are lost.
It appears that what is happening is that after the dialog is displayed, it is auto-selecting all text (containing what you have already typed) and therefore the next keystroke clears the selected search text, replacing it with the new key.
This bug is still present in version 11.03. Version 10.52 was the last working version.
Version 11.00 introduced a bug where any keys that you type before the window appears are lost.
It appears that what is happening is that after the dialog is displayed, it is auto-selecting all text (containing what you have already typed) and therefore the next keystroke clears the selected search text, replacing it with the new key.
This bug is still present in version 11.03. Version 10.52 was the last working version.
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
I hope you understand that all ordinary people FIRST of all is WAITING for the Search dialog box to open - and ONLY after that is starting to type on a keyboard...darrenmjones wrote: 2024-03-19, 13:35 UTC When you use Alt-F7 to Search, in version 10.52 and all prior versions of Total Commander you could start typing the search text immediately, and when the dialog appears, it would contain all keystrokes, even those you typed while the dialog was loading..
Nothing should happen in the void - when there is not even that dialog on the screen yet - which is what all these keystrokes are for.
imho BUG just was fixed finally)))
#146217 personal license
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
AntonyD,
Ordinary people use Explorer.
I have not checked the issue, but if it exists I lean to the side of "do not discard the buffered keys".
Roman
Ordinary people use Explorer.
I have not checked the issue, but if it exists I lean to the side of "do not discard the buffered keys".
Roman
Mal angenommen, du drückst Strg+F, wählst die FTP-Verbindung (mit gespeichertem Passwort), klickst aber nicht auf Verbinden, sondern fällst tot um.
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
If there really is a selection, the buffer isn't discarded but the keys just replaces the selection.
It probably depends on which control is the default control (that gets activated) in TC's Find Files window. Maybe there was a change in version 11.0.
It probably depends on which control is the default control (that gets activated) in TC's Find Files window. Maybe there was a change in version 11.0.
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
-
- Junior Member
- Posts: 20
- Joined: 2024-03-19, 13:30 UTC
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
Yes, in version 10.52 and all prior versions, if you type a single character or few characters, like "a" prior to the dialog appearing, the "a" would be there but would not be auto-selected. You could then continue typing more characters which would appear after the "a" in the search string.
With version 11.00 and later, when the dialog appears, the "a" that you typed before the dialog appeared gets auto-selected. So then the next character you type replaces the selection and you're starting from the beginning, having lost the "a" that you typed before the dialog appeared.
With version 11.00 and later, when the dialog appears, the "a" that you typed before the dialog appeared gets auto-selected. So then the next character you type replaces the selection and you're starting from the beginning, having lost the "a" that you typed before the dialog appeared.
-
- Junior Member
- Posts: 20
- Joined: 2024-03-19, 13:30 UTC
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
In my case, I'm often searching for something like "*mysearchstring*". And what happens is that the first few characters, say "*m", get entered before the dialog appears. They get auto-selected and then as I continue to type I only get the end of the string "ysearchstring*". This is annoying because I've lost the leading asterisk and so it doesn't find any matches.
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
I have tested and each typed letter before find window appears is inserted then in find field. If separated find process is used, the typed text goes out of find window.
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
"Ordinary" was used ONLY with links to those who is using exactly Total - NOT Explorer))))Hacker wrote: 2024-03-19, 15:12 UTC AntonyD,
Ordinary people use Explorer.
I have not checked the issue, but if it exists I lean to the side of "do not discard the buffered keys".
Roman
OK, "do not discard the buffered keys". Let's imagine that for some reasons the Search window will
NOT appear very quickly, it will wait for example exactly 2 seconds before it appears on the screen.
And let it be the completely expected 2 seconds - because the right thing will be done in the background
at this moment.
And you indeed will type "in the void" your search string?? just hoping that the whole buffered keystrokes
will go exactly where you need it? And do you think this is the correct logic of use? Honestly?
#146217 personal license
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
2AntonyD
I think every pc user does the tasks in some miniseconds advance in any program which use often because the acts are predictable. Many times it happens to me that after I click to open some window with input field where always field used to get focus I write text (despite the field was not shown yet) and I found the text was not typed in field because was extraordinary not in focus. It is the proof that we do things in advance and we are not aware it. Thus I do not think the typing in advance is extraordinary behaviour, it is normal automatic not-awared behaviour to do things quicker and programs would get along with it.
I think every pc user does the tasks in some miniseconds advance in any program which use often because the acts are predictable. Many times it happens to me that after I click to open some window with input field where always field used to get focus I write text (despite the field was not shown yet) and I found the text was not typed in field because was extraordinary not in focus. It is the proof that we do things in advance and we are not aware it. Thus I do not think the typing in advance is extraordinary behaviour, it is normal automatic not-awared behaviour to do things quicker and programs would get along with it.
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
AntonyD,
As a sidenote, sometimes it's also the most efficient way for AHK scripts - just let AHK type the letters, and even though the letters are typed faster than the windows appear, they keystrokes are processed properly. It's not the most correct way to do stuff, but for many things it just works.
Roman
If that's the way I've been doing it for the past ten years, then of course. If the computer can't keep up with my typing, I expect it to catch up with me. If I need to unpack something to a subdir of the current dir, by muscle memory I press Alt-F9,Del,Alt-S,Enter, and I don't wait for the unpack dialog to appear or check if the target path was deleted and checkbox checked. I typed the correct sequence and the computer should execute it. Don't tell me you don't have any memorized sequence where you just type it and expect stuff to happen automatically, instead of just waiting for each step along the way.Let's imagine that for some reasons the Search window will
NOT appear very quickly, it will wait for example exactly 2 seconds before it appears on the screen.
And let it be the completely expected 2 seconds - because the right thing will be done in the background
at this moment.
And you indeed will type "in the void" your search string?? just hoping that the whole buffered keystrokes
will go exactly where you need it? And do you think this is the correct logic of use? Honestly?
As a sidenote, sometimes it's also the most efficient way for AHK scripts - just let AHK type the letters, and even though the letters are typed faster than the windows appear, they keystrokes are processed properly. It's not the most correct way to do stuff, but for many things it just works.
Roman
Mal angenommen, du drückst Strg+F, wählst die FTP-Verbindung (mit gespeichertem Passwort), klickst aber nicht auf Verbinden, sondern fällst tot um.
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
I cannot even reproduce darrenmjones's problem - On my widows 7 system there is no time to type anything before the dialog is ready.
On my slow Window 10 laptop I have about 1- 1½ second before the dialog is ready, but even if I type within those 1½ second, nothing is lost.
2darrenmjones
Does it also happen if you start TC wit a fresh ini file?
How long does it in average take before your Find Files dialog is ready?
On my slow Window 10 laptop I have about 1- 1½ second before the dialog is ready, but even if I type within those 1½ second, nothing is lost.
2darrenmjones
Does it also happen if you start TC wit a fresh ini file?
How long does it in average take before your Find Files dialog is ready?
License #524 (1994)
Danish Total Commander Translator
TC 11.51 32+64bit on Win XP 32bit & Win 7, 8.1 & 10 (22H2) 64bit, 'Everything' 1.5.0.1391a
TC 3.60b4 on Android 6, 13, 14
TC Extended Menus | TC Languagebar | TC Dark Help | PHSM-Calendar
Danish Total Commander Translator
TC 11.51 32+64bit on Win XP 32bit & Win 7, 8.1 & 10 (22H2) 64bit, 'Everything' 1.5.0.1391a
TC 3.60b4 on Android 6, 13, 14
TC Extended Menus | TC Languagebar | TC Dark Help | PHSM-Calendar
-
- Junior Member
- Posts: 20
- Joined: 2024-03-19, 13:30 UTC
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
petermad,
Thank you! I tested on my 2nd PC and was unable to reproduce the problem
I uninstalled and wiped out my c:\Program Files install directory as well as the AppData\Roaming\<user>\GHISLER folder where my wincmd.ini file was located and reinstalled 11.03 and the problem seems to be gone.
There's maybe a 0.5-0.7 second delay before the dialog appears but now if I type a single character pre-dialog load, it does not come up with that character selected (which is why it was getting replaced as I continued typing).
I'm not sure how I got into that state but thank you very much for helping to solve the mystery, much appreciated!
Thank you! I tested on my 2nd PC and was unable to reproduce the problem
I uninstalled and wiped out my c:\Program Files install directory as well as the AppData\Roaming\<user>\GHISLER folder where my wincmd.ini file was located and reinstalled 11.03 and the problem seems to be gone.
There's maybe a 0.5-0.7 second delay before the dialog appears but now if I type a single character pre-dialog load, it does not come up with that character selected (which is why it was getting replaced as I continued typing).
I'm not sure how I got into that state but thank you very much for helping to solve the mystery, much appreciated!
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
That is very drastic - to test something like this it is usually enough to start TC with the parameter /i=%TEMP%\test.ini This will start TC configured from scratch. You only need to reinstall TC like you did, if you have a suspicion that one of TC's program files are corrupt.I uninstalled and wiped out my c:\Program Files install directory as well as the AppData\Roaming\<user>\GHISLER folder where my wincmd.ini file was located and reinstalled 11.03 and the problem seems to be gone.
If styarting TC with the parameter /i=%TEMP%\test.ini solves your problem, you can either try and find the problem in your wincmd.ini file, or delete your wincmd.ini file
License #524 (1994)
Danish Total Commander Translator
TC 11.51 32+64bit on Win XP 32bit & Win 7, 8.1 & 10 (22H2) 64bit, 'Everything' 1.5.0.1391a
TC 3.60b4 on Android 6, 13, 14
TC Extended Menus | TC Languagebar | TC Dark Help | PHSM-Calendar
Danish Total Commander Translator
TC 11.51 32+64bit on Win XP 32bit & Win 7, 8.1 & 10 (22H2) 64bit, 'Everything' 1.5.0.1391a
TC 3.60b4 on Android 6, 13, 14
TC Extended Menus | TC Languagebar | TC Dark Help | PHSM-Calendar
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
2Hacker
That's exactly what I wanted to say. It doesn't matter that I have memory for some actions - I ALWAYS wait for a visual response from the programs to make sure that everything will be done correctly...Don't tell me you don't have any memorized sequence where you just type it and expect stuff to happen automatically, instead of just waiting for each step along the way.
#146217 personal license
-
- Junior Member
- Posts: 20
- Joined: 2024-03-19, 13:30 UTC
Re: Bug introduced in 11.00, Alt-F7 Search loses buffered keystrokes
petermad,
Thanks for the tip. It wasn't a big deal to me. I didn't actually permanently delete those folders, just moved them to another location. I'd already been uninstalling and reinstalling between versions 10.52 and 11.03 to make sure the problem was reproducible in 11.03 but did not occur in 10.52. It seems weird that some setting in the .ini file could cause such an issue only in the 11.xx versions.
At the end of the day, I'm just happy to have a resolution to the problem because it was driving me so crazy for search not to work properly that I had decided to stay on the old version until it was fixed.
Thanks for the tip. It wasn't a big deal to me. I didn't actually permanently delete those folders, just moved them to another location. I'd already been uninstalling and reinstalling between versions 10.52 and 11.03 to make sure the problem was reproducible in 11.03 but did not occur in 10.52. It seems weird that some setting in the .ini file could cause such an issue only in the 11.xx versions.
At the end of the day, I'm just happy to have a resolution to the problem because it was driving me so crazy for search not to work properly that I had decided to stay on the old version until it was fixed.