[Bug] $exec Issue with 1.5.0.1254a

[aviasd]

Hi,
on version 1.5.0.1254a the custom exec option (for files and folders) seemed to have stopped working.
I have this set for open files/folders (Tools->options->context menu):

Code: Select all

$exec("tot.bat" "%1")

where tot.bat is a script to open total commander and %1 is the filename/folder selected.
When double clicking or selecting open with context menu, this is not working anymore.
on V.1.5.0.1253a it works without issues.

Thanks.

Update: on further inspection - if specifying the complete path to the script: e.g c:\utils\tot.bat, it is working again. scripts within %PATH% are not evaluated. this is not good for portability.

[void]

Thank you for your feedback aviasd,

Everything is treating the file as a virtual file.

Please make sure you specify the full path and filename in $exec().

For example:
$exec("C:\Everything\tot.bat" "%1")

I'll look into improving 'virtual file' detection.

[aviasd]

For example:
$exec("C:\Everything\tot.bat" "%1")

I'll look into improving 'virtual file' detection.

Thanks for the quick reply.
If improving 'virtual file' detection turns out to take time/has issues, please consider adding relative file paths as alternatives, as they also don't work right now.
E.G:

Code: Select all

$exec("..\tot.bat" "%1") 

to maintain portability..
Thx

[NotNull]

You can use relative paths. Those paths will be relative to the location of Everything.exe.

So when your Everytthing.exe is in C:\Program Files\Everything 1.5a and your tot.bat in c:\scripts, you can use:

Code: Select all

$exec("..\..\scripts\tot.bat" "%1")

or

Code: Select all

$exec("\scripts\tot.bat" "%1")

Shell environment variables, like %COMMANDER_PATH%, are not supported here.

[aviasd]

You can use relative paths. Those paths will be relative to the location of Everything.exe.

Are you sure about that?
on 1.5.0.1254a non of the variations of work ( relative or root of the drive)
on 1.5.0.1253a- (%path% and root of drive work )
Everything 1.4 - all three variations work. ( %Path%, relative, root of the drive)

Note: on 1.5.0.1253a. descending one directory to the script does not work (script is not found). e.g $exec("..\tot.bat" "%1") but descending and going back in for some reason works (script found) . E.G: $exec("..\..\utils\tot.bat" "%1")

[NotNull]

I'm on 1252 ... So not sure about 1253+ Will update and test ...

[NotNull]

1254:
Entirely different results compared to 1252 ....

- Relative paths (\folder , ..\..\folder, etc don't work.
- %PATH% is not used

However using environment variables now works.
If VAR=c:\folder is globally defined or in any other way known to EVerything, you can use

Code: Select all

$exec("%VAR%\tot.bat" "%1")

Didn't expect that behaviour to change between these versions (based on the list of changes) ....

[void]

The "fixed an issue with opening virtual files." change has broken relative paths when executing files.

Everything needs to be able to execute files like:
Control Panel\All Control Panel Items\Mouse

I'm working on a fix.
I will make $exec expect file system files only.

[aviasd]

I'd like to point out another issue with 1.5.0.1254a and $exec.

On 1.5.0.1253a (and older), the exec script would open the current file in total commander and activates total commander.

On 1.5.0.1254a, with absolute path to the script, the script does run and total commander opens the file but the window is not activated - I have to manually switch to the total commander window.

I'm guessing it's a change in how $exec is executing commands.

[horst.epp]

I'd like to point out another issue with 1.5.0.1254a and $exec.

On 1.5.0.1253a (and older), the exec script would open the current file in total commander and activates total commander.

On 1.5.0.1254a, with absolute path to the script, the script does run and total commander opens the file but the window is not activated - I have to manually switch to the total commander window.

I'm guessing it's a change in how $exec is executing commands.

I have the context menu entries point to Total Commander and it is started and also activated.
I don't see any need for a script here using 1.5.0.1254a

[aviasd]

I have the context menu entries point to Total Commander and it is started and also activated.
I don't see any need for a script here using 1.5.0.1254a

It's more of a user preference IMO.
In my case, I'd like to see the file in TC when I press enter or double click (overriding the default open command)
As TC is my goto tool and everything is the second goto, I'd like a tighter integration than via context menu..
Also, in terms of portability, TC's context menus might not be available on other machines

[horst.epp]

I have the context menu entries point to Total Commander and it is started and also activated.
I don't see any need for a script here using 1.5.0.1254a

It's more of a user preference IMO.
In my case, I'd like to see the file in TC when I press enter or double click (overriding the default open command)
As TC is my goto tool and everything is the second goto, I'd like a tighter integration than via context menu..

I have set TC as default file manager in the registry
so enter or double click opens TC in all cases and not only in Everything.
I also use the JumpToFolder tool from NotNull here in the forum.
This changes the current path in TC using an Everything search, very helpful.

[NotNull]

I think you guys (M/F) are on different wavelengths.
As I see it, Horst is asking why you (@aviasd) use a tot.bat instead of c:\path to\totalcmd64.exe /parms
Correct?

FWIW: the second one starts TC and activates it. Didn't test the first ( .bat) one.

[aviasd]

I think you guys (M/F) are on different wavelengths.
As I see it, Horst is asking why you (@aviasd) use a tot.bat instead of c:\path to\totalcmd64.exe /parms
Correct?

FWIW: the second one starts TC and activates it. Didn't test the first ( .bat) one.

Yes, running TC directly does activate it.

I'm using a wrapper script for different reasons:
1. I open paths in TC via various scenarios so a parsing script would need to accept those options: I.E: from cmd, from the clipboard, from everything, misbehaving apps in regards to quoting paths, and a few more..
2. When on a new machine the script will generate custom INI for TC (favorite folders) which is different than my regular workstations.
3. if I decide to make a change in the command line parameters for TC, I need to change it only in one place (the script) and not multiple places. I.E everything.ini, other scripts etc..
4. (which is getting obsolete as time passes) - detecting if I'm on 32bit machine and running the correct executable.

So you see, the script makes my life easier, I could use the direct invocation in everything without losing much but the cost of some convenience...

[NotNull]

In the meantime I tested the "tot.bat-way" too (in a couple of ways). Here (Win10 1909, Everything 1254) it always makes TC the active application.
I should know what might cause this under some conditions, but can't put my finger on it atm. Will chew on it ...

What happens on your end if you create a tot2.bat with a straightforward

Code: Select all

start "" "C:\path to\TOTALCMD64.EXE"

If TC is NOT running beforehand?

[aviasd]

In the meantime I tested the "tot.bat-way" too (in a couple of ways). Here (Win10 1909, Everything 1254) it always makes TC the active application.
I should know what might cause this under some conditions, but can't put my finger on it atm. Will chew on it ...

What happens on your end if you create a tot2.bat with a straightforward

Code: Select all

start "" "C:\path to\TOTALCMD64.EXE"

If TC is NOT running beforehand?

Well, after a little more digging here's what I found:
1. The straightforward way does not have this issue. I can only assume because the cmd window finishes a fraction faster (because of simplicity) but it's only an assumption.
(
The straightforward way outputs the exact output of my script.
I.E: start "" "C:\utils\tot\totalcmd64.exe" /o /a /r="C:\Windows\System32\PING.EXE"
)

2. I can reproduce the issue with the original script quite consistently - if I double click a file the moment tooltip should appear in everything, TC will not get focus, if I do it before or after the tooltip appeared - TC will get focus. ( can get this issue to reproduce in 1 out of 3 attempts)

I went on a hunch and put in everything.ini :
tooltips=0 ( was tooltips=1) and the problem went away. ( for my script)

If TC is not running beforehand it will start and activate without an issue.

BTW: in the help - tooltips=0 says it's disabling tooltips but in my case tooltips still appear.. (Maybe because of listview_tooltips=1 ? IDK)


..So it seems like some UI issue, after all.

[NotNull]

Nice digging, Sherlock

Can't help with taht; I can only guess that showing the tooltip shifts the focus back to Everything.

There are a couple of tooltip settings that might mitigate the issue.

You could try:

Code: Select all

tooltips=1
listview_tooltips=1
show_detailed_listview_tooltips=1

Then you will have the tooltips in the Opions dialog and tooltips when hovering the file/folder icon.

[aviasd]

Nice digging, Sherlock

Can't help with taht; I can only guess that showing the tooltip shifts the focus back to Everything.

I guess this mystery isn't solved yet... Tried resetting back to tooltips=1 to reproduce the issue before I posted this post, I could not reproduce it.
Haven't changed anything else though.
This is very odd - this issue was persistent for a couple of days. (Tested also with just TC and everything open, no other apps)
I'll let it simmer with tooltips=1 for a few days and will post back.

[void]

Thank you for the feedback aviasd,

Could you please try the latest Everything 1.5 Alpha.

Everything 1.5.0.1255a fixes an issue with executing relative $exec scripts.

Everything will now ignore the custom Open command for virtual files.
I have on my TODO list to add another separate Open command for virtual files.
The system will open virtual files for now.

I've also made the tooltips not 'activate' when shown. Could you please see if this helps with the tooltips stealing focus.

[aviasd]

Thank you for the feedback aviasd,

Could you please try the latest Everything 1.5 Alpha.

Everything 1.5.0.1255a fixes an issue with executing relative $exec scripts.

Everything will now ignore the custom Open command for virtual files.
I have on my TODO list to add another separate Open command for virtual files.
The system will open virtual files for now.

Ah, thanks
Relative $exec is working again
( %PATH% $exec does not, but the workaround is acceptable, maybe even preferred )

I've also made the tooltips not 'activate' when shown. Could you please see if this helps with the tooltips stealing focus.

I've actually encountered the issue again on 1.5.0.1255a, but it was only once in about 20-30 attempts (my test file run count is at 600!)
Will report back in a few days..

[void]

Thanks for the feedback aviasd,

( %PATH% $exec does not, but the workaround is acceptable, maybe even preferred )

I'll make some more changes here so commands in %PATH% will work.

I've actually encountered the issue again on 1.5.0.1255a, but it was only once in about 20-30 attempts (my test file run count is at 600!)
Will report back in a few days..

It might be a DDE communication issue.
1.5.0.1255a should wait for the DDE transaction to complete before closing any windows.
What type of files is causing the issue? -or is it folders only?

[aviasd]

It might be a DDE communication issue.
1.5.0.1255a should wait for the DDE transaction to complete before closing any windows.
What type of files is causing the issue? -or is it folders only?

Back then when it was consistent it would happen randomly without distinguishing filetypes or folders,
Now I cannot get it to reproduce.
My current test file is .mp4.

One thing to mention is: I do have a SHA-256 unindexed column set up... Maybe it's related... (although the tooltip does show an empty value for it when it's not scanned yet)

Note: I'm unsure which DDE transaction do you mean, but everything 1.5 is not running as a service.
Note2: Spy++ does not log any dde messages in everything's window

[void]

I do have a SHA-256 unindexed column set up... Maybe it's related...

It might be. Does the issue occur when the sha-256 column is not shown? Are you showing your results as thumbnails or with detailed view?
Everything does not request the sha-256 property when the column is off-screen in detail view.


Everything 1.5.0.1256a fixes an issue with executing scripts from the %PATH% folder.

[aviasd]

It might be. Does the issue occur when the sha-256 column is not shown? Are you showing your results as thumbnails or with detailed view?
Everything does not request the sha-256 property when the column is off-screen in detail view.

I'm using Detailed view,
The Sha-256 is offscreen.
It happened 6 more times on Everything 1.5.0.1256a ( out of ~150 attempts)
Still cannot point the finger on exactly what am I doing to cause the issue,
I can say that it happens on every filetype/folder.
I can say that sometimes I accidentally triple-click the file which causes everything's UI to stay focused, but that's on me..
I'll sit on it some more and see what I can come up with.

Everything 1.5.0.1256a fixes an issue with executing scripts from the %PATH% folder.

Confirmed, %path% scripts now working again

[aviasd]

I'll sit on it some more and see what I can come up with.

Well, it happened again, this time the issue was consistent until terminating everything.
The process was:

• Activate everything (via hotkey)
• Start typing a query.
• Browse to the result with the keyboard and pressing enter to activate (the script)

TC would go to the correct file and its taskbar icon would start blinking but the focus was on everything's UI.

Before terminating everything (File->Exit), I terminated TC and explorer.exe to see if that was the culprit - it wasn't.

Note: After termination, I started everything, the UI showed for a few seconds but then the process was terminated. Had to start for a second time. ( Debug logging was not on, so no logs, there wasn't a crash dump. 1.5.0.1256a (x64))

Note2:
I RDP in and out of the machine a lot and also use it locally as well.
From experience with RDP on Windows 10, I know it causes some UI issues, window rearrangements, etc - especially on >1 displays. (I'm on a 4 display system), so it could be related to that..

[void]

Hard to tell what is happening here, as Everything is only calling ShellExecuteEx.

Everything should have SetForegroundWindow privileges as it is in the foreground.
The new process should have SetForegroundWindow priviliges.
The issue is with the program (TC) called from your script not having SetForegroundWindow privileges.
The OS could be locking SetForegroundWindow somewhere during ShellExecuteEx

Everything does use a temporary window while calling ShellEexecuteEx which might be the issue.

The temporary window is needed to prevent Everything from losing focus when the UAC prompt is shown.

Could you please try disabling this temporary window:

• In Everything 1.5.0.1258a, type in the following search and press ENTER:
  /shell_execute_window=0
• If successful, you should see shell_execute_window=0 in the status bar for a few seconds.

What happens if you call your script contents directly from Everything $exec? -Does the issue occur?

[aviasd]

Could you please try disabling this temporary window:

• In Everything 1.5.0.1258a, type in the following search and press ENTER:
  /shell_execute_window=0
• If successful, you should see shell_execute_window=0 in the status bar for a few seconds.

I've set /shell_execute_window=0 on 1.5.1258a, I'll wait for a while to see if it happens again.

What happens if you call your script contents directly from Everything $exec? -Does the issue occur?

I could not reproduce it using calling TC directly (w/o script), but it was only a short test. if /shell_execute_window=0 won't work I'll try direct invocation and report...

[void]

Everything 1.5.0.1262a now sets the working directory when calling a script.

For example:

$exec("C:\Program Files\Q-Dir\GO.BAT" "%1")

[aviasd]

So, I'm pretty sure this bug has something to do with explorer/RDP
(RDP on win 10 does a lot of window resizing (Maybe more on a multi-display system) - even Visual studio display gets messed up after an RDP session)

The focusing problem mostly occurs when rdp'ing into my machine or after re-logging in after an RDP session.

I've had an occurrence where the focusing problem happened on everything 1.4 but did not happen on everything 1.5.
I'm not sure what's going on.

As a side note - this issue has been much rarer lately (I think since 1.5 v1259)