Quick Search filter shows empty panel after closing launched app with Esc

[ghisler(Author)]

Yes, this works perfectly.
I tested opening and closing i_view32.exe with ESC — the filtered results remain displayed as expected, and the filter is preserved.

OK, so the problem is actually Quick Search Extended and not the option to allow zero file results.

Regarding the “allow zero file result” behavior — is there any way to configure this?
In practice, I would prefer allow_empty_result=0, this would better match my workflow

I agree. Do you still have the old tcmatch.dll from yesterday? Then use that and copy tcmatch.tbl to tcmatch64.tbl.

[zhugecaomao]

OK, so the problem is actually Quick Search Extended and not the option to allow zero file results.

Yes, exactly, the problem is actually Quick Search Extended and not the option to allow zero file results.

I agree. Do you still have the old tcmatch.dll from yesterday? Then use that and copy tcmatch.tbl to tcmatch64.tbl.

Yes I have the old tcmatch.dll dated 18 May 2026, and I use that and renamed tcmatch.tbl to tcmatch64.tbl, this works perfectly.

1. Tested opening and closing i_view32.exe with ESC — the filtered results remain displayed as expected, and the filter is preserved.
2. Pinyin filtering is working.
3. “Not allow zero file result” is working.

[ghisler(Author)]

Great! I'm moving this thread to the plugins forum. When I find some time, I will check the sources of Quick View Extended to find out what the problem could be.

Moderator message from: ghisler(Author) » 2026-05-19, 16:12 UTC

Moved to plugins forum

[zhugecaomao]

2ghisler(Author)

Thanks! I have also reported this issue in the following thread for reference: viewtopic.php?p=484845#p484845

[Samuel]

Its not a bug, its a feature.

At the beginning of the main compare-function there is a simple check if ESC is pressed to prevent a long waiting period.

Code: Select all

// main compare function
int __stdcall MatchFileW(WCHAR* wcFilter, WCHAR* wcFilename) {

    // Interrupt the match process while ESC is pressed
    // could be used when the match process is slow, because a long text is pasted or plugins slow down the process
    if(GetAsyncKeyState(VK_ESCAPE)) return 0;

Was introduced in

Code: Select all

Version 2.2.7
- Added pressing and holding ESC interrupts the matching process. Could be used when the match process is slow, because a long text is pasted or plugins slow down the process.

[AntonyD]

So this code is supposed to only work at the moment when the loading occurs. A really long loading (we set a timer).
But what happens here? We immediately get the result - the plugin HAS ALREADY EXECUTED its code/work, and then
suddenly the key press of ANOTHER application is intercepted by the plugin and counted as an action in its favor????

[zhugecaomao]

So this code is supposed to only work at the moment when the loading occurs. A really long loading (we set a timer).
But what happens here? We immediately get the result - the plugin HAS ALREADY EXECUTED its code/work, and then
suddenly the key press of ANOTHER application is intercepted by the plugin and counted as an action in its favor????

Agreed with AntonyD. This behavior does not seem correct, seems the plugin may be intercepting input events beyond its intended scope.

[Samuel]

This code currently has no timer or debounce logic attached to it. During every match operation, it simply checks at the very beginning whether the ESC key is currently pressed:

Code: Select all

if(GetAsyncKeyState(VK_ESCAPE)) return 0;

So the behavior here is most likely the following:

- TC launches IrfanView from the filtered result list.
- The user presses and holds ESC to close IrfanView.
- IrfanView closes immediately.
- Total Commander regains focus and refreshes/re-evaluates the current filtered file list.
- During that refresh, MatchFileW() is called for every file.
- Since ESC is still physically pressed at that exact moment, every call returns "no match".
- As a result, the panel becomes empty.
- The user releases ESC shortly afterwards.

All of this happens within just a few milliseconds.

So the plugin is not actively intercepting or globally capturing keyboard input from another application. It merely checks the current asynchronous keyboard state at the moment the filter function executes. The issue is therefore more of a side effect of the current implementation and timing rather than intentional cross-application input handling.

[zhugecaomao]

So the behavior here is most likely the following:

- TC launches IrfanView from the filtered result list.
- The user presses and holds ESC to close IrfanView.
- IrfanView closes immediately.
- Total Commander regains focus and refreshes/re-evaluates the current filtered file list.
- During that refresh, MatchFileW() is called for every file.
- Since ESC is still physically pressed at that exact moment, every call returns "no match".
- As a result, the panel becomes empty.
- The user releases ESC shortly afterwards.

All of this happens within just a few milliseconds.

So the plugin is not actively intercepting or globally capturing keyboard input from another application. It merely checks the current asynchronous keyboard state at the moment the filter function executes. The issue is therefore more of a side effect of the current implementation and timing rather than intentional cross-application input handling.

Thank you for the clarification.

I have to say that in most cases it works well — for example, when launching the F3 Lister or opening files like Notepad from the filtered result list, pressing ESC closes them, the filtered result maintains as expected.

Only some applications (e.g. IrfanView or ALTRun) have this issue. And ghisler's simple tcmatch.dll do not have this issue as well.

Since this is considered a feature rather than a bug, is there any way to configure or control this behavior? Much appreciated

[AntonyD]

Maybe it still makes sense for such behavior to pay attention to REPEATED (2+) presses of this button? If we try to theoretically reproduce a situation where we get a very slow output, too long filtering, the user usually behaves quite predictably in such moments – they get nervous. Which means they will nervously press ESC (2/3/4.. times), it's just psychology, & not calmly and melancholy – as they would behave in a case when they just need to simply and calmly close one running program. There, this key will clearly be pressed only once and carefully.

[Samuel]

I assume the reason why the internal Lister works correctly is that it probably waits for the ESC key to be released (key-up) before returning control to TC again.

Applications like IrfanView most likely close immediately on key-down, while the ESC key is still physically pressed. Therefore, when TC regains focus and starts re-evaluating the filtered list,

Code: Select all

GetAsyncKeyState(VK_ESCAPE)

still reports ESC as active for a very short moment.

Regarding the suggestion about repeated ESC presses: I think there is a misunderstanding about how the current implementation works.

Code: Select all

MatchFileW()

is called by Total Commander without any larger context. The plugin only receives independent match requests for individual files. I do not know:

- when a filtering operation starts,
- when it ends,
- whether more calls will follow,
- or whether TC is currently in a “slow filtering” state at all.

Because of that, there currently is only this very rudimentary check directly at the beginning of each match call:

Code: Select all

if(GetAsyncKeyState(VK_ESCAPE)) return 0;

So there is currently no state machine, timer, debounce logic, or “counting of ESC presses” behind it. The plugin simply checks the current keyboard state at that exact moment and aborts the match if ESC is still pressed.

I currently do not plan to change this behavior, since the ESC interruption was intentionally added as a simple safeguard for potentially slow filtering operations.

However, I may add an optional setting for this in a future version.

[ghisler(Author)]

A simple solution would be to check whether VK_ESCAPE is UP during the first call of the function after it wasn't called for , say, 100ms. If yes, the ESC key must be ignored until it is up again, or MatchFileW wasn't called for at least 100ms.