Two search tools in the same shell?

[vefatica]

I use the TCC.EXE shell from JPSoft on Windows 10. It has a built-in EVERYTHING command and my own plugin for the shell implements an ES command. Both EVERYTHING and ES are command line search tools. In any instance of the shell the one of those commands used first works (and continues to work) while the one used second fails (and continues to fail). Neither produces an error message. This is the case for both elevated and non-elevated instances of the shell.

Any idea what would cause only the first-used of the commands to work?

I think the set-up is pretty normal. The service is running, and the client server is running unelevated, both started eariler. I can provide more info (especially about ES).

[NotNull]

From what I know about TCC:

TCC uses Everything 1.5 these days, so it liekly does not use the SDK to communicate with a running Everything, but an adaptation of voidtools' ES command-line tool sourcecode.
TCC calls it EVERYTHING; you created a personal variation and called it ES too.
EVERYTHING is an internal command to TCC; your ES runs as an external command? (i.e. ES.exe?)


I do not have a solution, but some pointers that might help:

• What do "which ES" and "which EVERYTHING" report? (or was it "where"?)
• Enable the debug console in Everything to see what messages Everything receives: Menu => Tools => Debug => Console (optionally enable the Verbose mode too).
  To close the debug console: Menu => Tools => Debug => Console
• What happens when using the ES.exe provided by voidtools instead of your own? Especially interested in the case where ES is started firste, then EVERYTHING. EVERYTHING and (your) ES might not close the connection, which might disallow other applications to use it. I'm assuming the 'regular' ES.exe handles that correctly.

[vefatica]

ES.EXE always works (not sure if it's yours, or my build of your code).

v:\> which es
es is a plugin command (ES)

v:\> which everything
everything is an internal command

The plugin ES.DLL is auto-loaded when TCC starts. It exports the ES command. It is dymanically linked to Everything64.dll which is loaded when the plugin DLL is loaded.

TCC's EVERYTHING is not dynamically linked. As far as I know, it's wholly contained in TakeCmd.dll.

I know nothing about any "connections". If ES or EVERYTHING is automatically getting a "connection" when first-used (preventing the other from working) , how can the connection be closed and re-opened? When the plugin DLL is loaded, it does nothing everything-related except for adding the message filter. When the ES command is called it does an Everything_Reset() and after parsing args and setting Everything options, does

Code: Select all

	if ( !Everything_QueryW(TRUE) )
	{
		Qprintf(STD_ERR, L"Everything_Query error: %lu\r\n", Everything_GetLastError());
		goto exit;
	}

So I'd see a message if it failed (I don't). The ES command does another Everything_Reset() when it returns.

How, exactly, do I enable the debug console? I can't find anything in the search GUI.

[NotNull]

I know nothing about any "connections"

Neither do I. Looking for causes, that seemed/seems a theoretical possibility.

How, exactly, do I enable the debug console? I can't find anything in the search GUI.

So you are using Everything 1.4? In that case: type or paste the following in the search bar and press ENTER:

Code: Select all

/debug

To close the debug console, repeat.

[vefatica]

Both searches are successful (ES first, EVERYTHING second). Both debug traces mention a return window. But only one (ES) produces output in the shell.

Here are the debug traces (ES first) with some irrelevant stuff removed.

Code: Select all

search ' xhistory32' filter '' sort 0
term 000000000300b9e0, flags: 3140, next: 0000000000000000, notnext: 0000000000000000
folderop: 2, fileop: 2, term: xhistory32
SET SORT 0
found 0 folders, size 0, db search time taken: 0.008422 seconds
found 1 files, size 65544, db search time taken: 0.012760 seconds
set sort 0 1
already sorted
finished sort, time taken 0.000771 seconds
update selection 0.000001 seconds
DB_WAIT: _db_ready_proc waiting...
DB_WAIT: _db_ready_proc waited 0.000081 seconds
IPC: query complete: 4294967295 max results, offset 0, reply hwnd 4261556
IPC: watch awake
IPC: Client disconnected.

search 'xhistory32' filter '' sort 0
:term 000000000300bf30, flags: 3140, next: 0000000000000000, notnext: 0000000000000000
folderop: 2, fileop: 2, term: xhistory32
SET SORT 0
found 0 folders, size 0, db search time taken: 0.006830 seconds
found 1 files, size 65544, db search time taken: 0.013977 seconds
set sort 0 1
already sorted
finished sort, time taken 0.000752 seconds
update selection 0.000000 seconds
DB_WAIT: _db_ready_proc waiting...
DB_WAIT: _db_ready_proc waited 0.000155 seconds
IPC: query complete: 4294967295 max results, offset 0, reply hwnd 16189372
IPC: watch awake
IPC: Client disconnected.

[vefatica]

Can we try again? Recap: TCC has the built-in EVERYTHING command. In a plugin DLL there's an ES command. The two are similar. In any given instance of TCC the first of those used works and continues to work and the second doesn't work. With a bit of debugging code in ES this is what I see when I try EVERYTHING, then ES.

Code: Select all

v:\> everything d:\tc35\es.exe
D:\tc35\es.exe

v:\> es d:\tc33\es.exe
dwResults = 0

v:\> 

ES contains the following code.

Code: Select all

if ( !Everything_QueryW(TRUE) )
	{
		Everything_PrintErrorMessage(rv = Everything_GetLastError());
		goto exit;
	}
	rv = 0; // looks like success

	DWORD	dwDirs = 0, dwFiles = 0, dwResults = Everything_GetNumResults(), dwPrintCount = min(num, dwResults);
	Printf(L"dwResults = %lu\r\n", dwResults);

So it looks like there were no results. But the debug console seems to show both searches returning 1 result. Here are clips from the debug session, EVERYTHING first, ES second.

Code: Select all

IPC: execute query: d:\tc35\es.exe
search 'd:\tc35\es.exe' filter '' sort 0 ascending 1
FOLDER TERM START 000000000161ca18 M 000000000131ea80 N 000000000131e830
000000000161ca18 20e01104 M 000000000131ea80 N 000000000131e830 OP 163 d:\tc35\es.exe
FILE TERM START 000000000161ca18 M 000000000131ea80 N 000000000131e830
000000000161ca18 20e01104 M 000000000131ea80 N 000000000131e830 OP 163 d:\tc35\es.exe
found 0 folders with 12 threads in 0.001087 seconds
found 1 files with 12 threads in 0.005019 seconds

IPC: execute query: d:\tc33\es.exe
search 'd:\tc33\es.exe' filter '' sort 0 ascending 1
FOLDER TERM START 000000000161ca18 M 000000000131ea00 N 000000000131e7b0
000000000161ca18 20e01104 M 000000000131ea00 N 000000000131e7b0 OP 163 d:\tc33\es.exe
FILE TERM START 000000000161ca18 M 000000000131ea00 N 000000000131e7b0
000000000161ca18 20e01104 M 000000000131ea00 N 000000000131e7b0 OP 163 d:\tc33\es.exe
found 0 folders with 12 threads in 0.001124 seconds
found 1 files with 12 threads in 0.004842 seconds

If I do the two commands in the other order I see this.

Code: Select all

v:\> es d:\tc33\es.exe
dwResults = 1
D:\tc33\es.exe

v:\> everything d:\tc35\es.exe

v:\>

[void]

The requests look OK, the queries look OK, maybe there's something up with the search result-window or shared reply window.

There should be another message in the debug log that looks like:

Code: Select all

IPC: query complete: 4294967295 max results, offset 0, reply hwnd 0000000000853b5c

What is shown if you perform these requests again?
I will add more debug information in the next Everything update.

What does the ES query code look like?

[vefatica]

Those lines are there. They show different HWNDs.

Code: Select all

IPC: query complete: 2147483647 max results, offset 0, reply hwnd 0000000000360a56
IPC: query complete: 4294967295 max results, offset 0, reply hwnd 0000000000540712

Before EverythingQueryW() I just set options.

Code: Select all

	psearch = SkipArgs(psz, argv, i);
	//Printf(L"psearch = **%s**\r\n", psearch);
	Everything_SetMatchCase(match_case);
	Everything_SetRegex(regex);
	Everything_SetMatchPath(match_path);
	Everything_SetMatchWholeWord(match_whole_word);
	Everything_SetMax(EVERYTHING_MAX_RESULTS);
slashv: // goto here with "/L", search string is "root:"; skip setting other options
	// process-wide; will allow me to be elevated when client server is unelevated
	//ChangeWindowMessageFilter(WM_COPYDATA, MSGFLT_ADD);
	StripEnclosingQuotes(psearch);
	Everything_SetSearchW(psearch);
	Everything_SetRequestFlags(dwRequestFlags);

[void]

The result-window is fine (all results requested)
I'll make a post here once I have the next update ready with more debug information.

Your code also looks fine.
Is it some sort of timing issue? do you see the same results if you wait a minute between the two calls?

[vefatica]

It's the same with a 5 minute wait between. As I said before, in any given instance of TCC, the one (TCC's EVERYTHING or plugin ES) used first continues to work and the other one never works.

[void]

Everything 1.5.0.1405a adds more debug information.

What is shown in the Everything debug console after an IPC request from TCC and swapping the command?