QuickSearch eXtended

[Samuel]

As there is nothing like this Rank, I use only the last part of the path (file or folder) for matching otherwise there could be many irrelevant results.
So this is as intended, as the API misses a rank.

Nothing like this should apply when your plugin is called for this new object - a menu with frequently used directories. In it, the work of the filter should support both the search in the middle and the search with * - because it is only a list of text strings, not objects of the file system.

Could you give an example how your tab is named? Here I tried to name a tab "abc\def" and couldn't find "abc" with QuickSearch eXtended and also TCs internal search doesn't find "abc". If you name the tab "abc > def" instead both searches find "abc".

For the plugin there is no difference, if it is called from a file panel (where it is a good idea to strip the path), or if it is called from the tab list. The plugin has no idea if it is in a folder searching for files or if it is searching for tab names.

[Samuel]

Just mentioned there is a search for tabs and for history entries. But the same applies there.
TCs internal search doesn't find "abc" for a folder "C:\abc\def\" - it finds "def" though.

[AntonyD]

Sorry - do not understand why we use 'tabs' word in this case.
We have only strings! And yes - if you want to start fuzzy search with TC's help - start typing desired text with *
I just found out about it recently, too. It didn't seem to work before.
Also here we talk only about new* menu with the history of recently visited directories.
It is also called by the combination Alt+DOWN.

P.S. *- means: It was there before of course - it's just that now it's rendered with new features as a separate dialog instead of just a standard context menu (a-la win32api) with its processing limitations...

[Samuel]

The TC quick search plugin is used to:
- 1. filter the file panels
- 2. filter search results in file panels
- 3. TC11: filter the list of open tabs
- 4. TC11: filter the list of recently visited directories

I referred to 3 in my first post today (tabs) and to 4 in my second post today. You seem to refer to 4 in your posts.

Please understand that:
- a) TCs internal quick search plugin has the same behavior. (deinstall QuickSearch eXtended and see what happens)
- b) For the quick search plugin there is no way to determine if 1, 2, 3 or 4 is the current search context.

Simple words: Currently no plans to change anything. Feel free to contribute code.

[AntonyD]

deinstall QuickSearch eXtended and see what happens

Already - And AFTER that TC's internal search/filter functionality based on input strings like:
*cmd
*wa
(which means * followed by some other expectable letters from strings which I wanted to filter/to search in) is beginning to work again;)
With your plugins it does not work either.

For the quick search plugin there is no way to determine if 1, 2, 3 or 4 is the current search context.

definitely if you'll cooperate about that problem with mr.Ghisler - you together can make this problem get solved easily...

[Samuel]

Please read the readme, it specifies how the supported searches work. There is no special handling for the "*"-char.

[AntonyD]

There is no special handling for the "*"-char.

special? what do you mean? tcmatch.pdf does contain the examples of working with that combinations:

Search for: “*dwn”

But looks like it does not work at all in modern TC in
- 3. TC11: filter the list of open tabs
- 4. TC11: filter the list of recently visited directories
Because only if I will remove plugin - this combination starts work in TC's search/filter GUI dialog,
issued in these cases... Yes, I really do not understand what are you trying to explain.
Does plugin not work correctly in these new GUI elements? Yes|No?
My answer is Yes, it does not. You are trying to answer No?? because "There is no special handling for the "*"-char."?

P.P.s.
I also fully understand that there may be difficulties due to the language barrier. I have to translate and comprehend phrases already in my own language. Therefore, if for clarification - for the ACCURACY of the explanation - it would be better to indicate something in the pictures - I would be grateful for such a form of answers.... thx in advance!

[Samuel]

The TC quick search plugin is used to:
- 1. filter the file panels
- 2. filter search results in file panels
- 3. TC11: filter the list of open tabs
- 4. TC11: filter the list of recently visited directories

Dear @Christian, can you please clarify if the current behavior is intended?

a) A folder like "C:\abc" is given to the plugin as "abc" when searching for "a" in the place 3.
b) A folder like "C:\abc" is given to the plugin as "C:\abc" when searching for "a" in the places 1, 2, 4.
c) A folder like "C:\abc" is given to the plugin as "C:\abc" when searching for "*a" in the places 1, 2.
d) A folder like "C:\abc" is given to the plugin as "C:\abc\" when searching for "*a" in the places 3, 4.

(d) sounds like a bug to me. It results into my current implementation of QuickSearch eXtended thinking there is an empty file name, finding nothing when searching for a string starting with "*".

[Max33Verstappen]

The "*" is now a meta-character used by TC11 in "Filter the list of recently visited directories" -- that is context 4, but not in the other contexts, like what's been stated in the changelog:
- Quick search in whole path by starting search strings with an asterisk.
It's only possible to achieve this by using the internal quick search.

[Samuel]

Update. Version 2.3.0 is available.

Code: Select all

Version 2.3.0
- Added: In the Total Commander 11 beta there is a new quick search in the folder history and in the list of currently open tabs. In both of these places, the entire path can be searched by prefixing the search with a "*". This is a Total Commander feature. Therefore, in this case, Quicksearch eXtended ignores the first character in the filter ("*") and searches the entire path instead of just the file name.

[AntonyD]

Version 2.3.0 is available.

Cool! Looks like *-bug has gone! Cool!
But one problem is still here: https://ibb.co/S7j9JC4
This is the problem of creeping onto other objects. More precisely, its opposite result.
The screenshot shows a very borderline situation, but nonetheless often encountered. This is when this new hot-dirs list/menu contains so many entries that the bottom of it touches the Windows taskbar. Then when we call the search/filter dialog it should be drawn on top of this panel! And as we see it on a pic - it succeeds. Look at the yellow line: It underlines the bottom border of this dialog, which is ABOVE this win.panel. And that's right! And now pls. take a look on the next form - the main dialog of your plugin. Only the top of its head sticks out of it - I outlined it with a green line. The Windows task bar simply cuts off its lower part.
In addition to this obvious case, it also happens that this new menu/list itself overlaps the main form of your plugin. This happens when the names of the visited directories are veeeeeeery long and the width of this new menu/list will be very large. And here we will get a opposite situation - the top of the main dialog of your plugin now will be cut off.

Maybe we should simply set HWND_TOPMOST flag on the main form of you plugin?

[Samuel]

This Autohotkey-GUI is already "AlwaysOnTop":

Code: Select all

Gui,+AlwaysOnTop -Border +ToolWindow

see: https://www.autohotkey.com/docs/v1/lib/Gui.htm

I cannot reproduce any problems here. The taskbar and the TC controls are below the GUI.

[AntonyD]

This Autohotkey-GUI

So maybe this is where the problem lies? In Total, all windows are real windows objects, completely created from scratch in the PAS code. Autohotkey-window = although it creates windows objects in the same way, it does it clearly in some kind of peculiar style.
I have this problem can be reproduced very permanently and easily. Maybe you can do something so that for the purpose of debugging this window writes its coordinates and the state of the flags to some log, including "TOP-MOST"?

P.S.
I can even say more - I was able to make this window constantly visible exactly in the state from my picture (when part of the window is UNDER the taskbar) and if I poke it with the cursor - I put it in focus - then this window pops up on top of the taskbar. BUT it is enough for me to move the focus to the taskbar - as it again easily overlaps with itself part of the form of your plugin as on my picture.

[Samuel]

I cannot reproduce the taskbar thing, hard to change something without seeing it. You could try to change the Code of the AutoHotkey Script yourself.

[AntonyD]

The problem with showing Above/Under objects for the plugin form is also different with the bitness change.
In 32-bit Total, your plugin's form is drawn ABOVE new menus, but BELOW Windows taskbar.
In 64-bit Total, the form of your plugin is drawn UNDER and new menus and UNDER Windows taskbar.

Also pls take a look at changelog:
06.06.23 Fixed: Quick search in history: set history window as parent so we don't get a separate taskbar icon for the quick search window (64)
IMHO very strange fix, I did not saw something similar. Very interesting in which conditions such bug could happen early?
But still, please note that some processes related to the Z-order of windows were still being done - and maybe your code was somehow hooked too?

Also, the plugin does not evaluate the available distance/position - where it can be displayed in full.
So if I open Total in full screen and call the menu of all open tabs on the right file panel - and after that I'll press * = and call the quick search / filter field along with your plugin - so the search field along with the menu will be drawn with a noticeable "jump" much more to the left than without this field. This is done by Ghisler in order to ensure that both the search field and the menu itself with long tab title/path names will properly and fully visible for user. BUT he doesn't take into account that you draw your plugin's form to the RIGHT of its search box. As a result, there is not enough space left for your form to be fully visible. And I'm not talking about the fact that the form will be overlapped by the menu itself - as if the TOP_MOST flag was completely removed from the form of your plugin.