QuickSearch eXtended

[Pawel]

Thanks for your reply.
I'd be happy to help but I have no C++ knowledge, unfortunatelly.
However, I am sure plenty of users use TC with Dark Colours. It looks not good with that light interface.
Would be great if You (maybe you change your mind) or someone with skills could do this. Really.

Btw, thank you for your great utility!
Have a nice day!
-Pawel

[hi5]

Feel free to contribute.

Just curious, the tcmatch64.exe and tcmatch.exe are compiled versions of "tcmatch.ahk" which in turn is actually the Gui shown when using TCMatch?

[Samuel]

That's correct.

[hi5]

Without an external class it is difficult to change button colors.
Here the background of the search gui is simply black: (ignore the missing icons) you can see the buttons remain the same color as non-dark
https://github.com/hi5/_resources/blob/master/tcmatch-search.png

As an example I've used an external class in the settings so I colored "some" controls, one light grey in the second tab, and blue/grey in the third tab.
Otherwise they will keep having a black (example tab 2) or white background (example tab 3) which is either to difficult to read or too bright.
Then again settings isn't something you change often I imagine so "80% dark" is acceptable I suppose.
https://github.com/hi5/_resources/blob/master/tcmatch-settings.gif

It is a few lines of code:

IniRead value Darkmode 0/1


If DarkMode
{
Gui,1:Color, Black
Gui,2:Color, Black
Gui,2:font, cwhite
}

Colouring the buttons IS possible but requires a second external class, both classes (controls & buttons) are easy to #include and easy to use.
In that case nearly all controls would require a hwnd + a call to the class to set the colors so that would add quite a bit of code, but that can be wrapped in an "If DarkMode" and if the hwnds are named wisely, no doubt looped.

Going a step further would to allow tcmatch to read the colors from wincmd.ini in case the user has made their own theme, but that would be pushing it.

[yyang]

Hello Samuel, I'm a long-time user of QuickSearch eXtended and benefit from it everyday. Recently I did some digging into the source code and found some minor issues like character conversions, memory leaks, etc. Is it possible to contribute code via GitHub or something else? Thanks.

[hi5]

tab2 should also be updated to tab3 - https://www.autohotkey.com/docs/v1/lib/GuiControls.htm#Tab

[qweewert]

hi

1. how in plugin specify second sub option. DirSizeCalc for example ("DirSizeCalc.Size.MiB").What the delimiter to do this?

2.How to load native "tc" plugin eg.. (tc.path|tc.size|tc.comment, how set path to it.

[Max33Verstappen]

I find there's a bug when a searching string starts with "*".
In the normal file list, the search begins from the very first char (e.g.: the drive letter for the local path) of the current dir the file list is in.
E.g.:
When the file list panel is currently inside "c:\Program Files", and I type the search string

Code: Select all

*c:\Program

, the cursor can walk through all the files and folders in the list, which means I can type

Code: Select all

*c:\program files\windows defender

to match "Windows Defender" when TC is actually inside "c:\program files".
Image: https://www.imagebam.com/view/MEPGNAW

The searching string beginning with "*" behaves even more strangely in the "Directory History" list. ("*" should only make the following string search the whole path of the entries in the history list, but now it PREFIXES the current path of the LEFT file panel to the entries of the "Dir History")
E.g.:
Currently the LEFT file panel is inside the "c:\program files" and there's a dir "c:\windows\..." in the "Dir History" list, I can match this entry by typing

Code: Select all

*c:\program files\c:\windows\...

Image: https://www.imagebam.com/view/MEPGNLQ

If I'm on the RIGHT file panel, and open the "Dir History" from there, all the entries searched by string beginning with "*" are prepended by the current dir of the LEFT panel.


The consequence of this is:
When the string you want to search in the list (History or File Panel) partially coincides with the path of the current "File Panel", it's impossible to find what you want by just typing a few characters(b/c: every entry can be a match if the search string is not long enough).

[Horst.Epp]

2Max33Verstappen
There is no problem here.
If you start a search in the history with a "*" it allows matches anywhere in the string
without the * it will search from the beginning.

[Max33Verstappen]

2Max33Verstappen
There is no problem here.
If you start a search in the history with a "*" it allows matches anywhere in the string
without the * it will search from the beginning.

I think you didn’t read my post carefully.
I know what “*” is supposed to behave. But now search string starting with it cause it to PREFiX the path of the current FILE PANEL to the entire string.
And it also affect the normal search in the “File List”.

Please read the problem carefully.

Do NOT filter the search result, BTW. The problem won’t be presented if the results are filtered.

[AntonyD]

2Max33Verstappen
To be honest, it’s completely unclear why you put this symbol BEFORE the entire path,
which you then define in its entirety. The asterisk is only useful and logical INSIDE the path.

[Horst.Epp]

Do NOT filter the search result, BTW. The problem won’t be presented if the results are filtered.

But that's what I do.
For me the normal behavior, and as you says without your problem

[Max33Verstappen]

2Max33Verstappen
To be honest, it’s completely unclear why you put this symbol BEFORE the entire path,
which you then define in its entirety. The asterisk is only useful and logical INSIDE the path.

• In "History List":
  If there's only one entry in the list, for example: "C:\Windows\System32", and my LEFT PANEL is now inside "C:\Program Files\". Using TC's own search, you can't even type in "*C:\Program Files", because there's no such entry in the list. But with QuickSearch installed, I can type in "*C:\Program Files". Why? Because the LEFT FILE PANEL is in the dir "C:\Program Files", and the QuickSearch also searched it, when there's a leading "*". So I suspect the actual string being searched is "C:\Program Files\C:\Windows\System32", when there's a leading "*". Without the leading "*", of course there's no problem, because you can only search "System32".

• In the normal File List:
  I put the "*" BEFORE the query string to test if this bug also exists in the normal file list, and I found it also exists. With TC's own search, there's no such problem (i.e.: I can't even type in "*C:\Program Files\", because there's no such path in the list)

I hope I stated it clear enough, and it would be great if you can try it yourself.
And forgot to mention that "To use the search Srch the search text has to start with a “*”.", so the leading "*" in the normal file lists also has its own job .

[Max33Verstappen]

Do NOT filter the search result, BTW. The problem won’t be presented if the results are filtered.

But that's what I do.
For me the normal behavior, and as you says without your problem

Can you try what I stated in the previous post, please?
Steps:
Go to "C:\Program Files" from the LEFT file panel-> Open "Histroy List" from there. -> See if you can type in "*C:\Program Files\", and move the ↑ or ↓ cursor through all the entries in the list.

If you can, there's a problem.

[Horst.Epp]

Can you try what I stated in the previous post, please?
Steps:
Go to "C:\Program Files" from the LEFT file panel-> Open "Histroy List" from there. -> See if you can type in "*C:\Program Files\", and move the ↑ or ↓ cursor through all the entries in the list.

If you can, there's a problem.

In this case, C:\Program Files is shown as actual on top of the list.
I can't enter C:\Program Files\ it stops after c: and shows only this in the list
but I can search for other entries from the list.
Starting with a * I can search for C:\Program Files without problems.