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.