1.2.1.371 sending wrong filenames to context menu extensions

[olliholliday]

I think I've found a problem with the filenames that Everything generates for sending to the context menu, I'm writing a shell extension that operates on the selected files and often the paths returned don't exist.

e.g. files in a folder somewhere:
/1/1111.txt
/1/2111.txt
/2/11111.txt
/2/21111.txt

search in everything for 111.txt and the results are:
1111.txt
11111.txt
2111.txt
21111.txt

select all the files, right click - at this point the paths Everything will generate for the context menus to operate on are:
/1/1111.txt
/1/11111.txt
/1/2111.txt
/1/21111.txt
I.e. the context menu is assuming that all selected files are in the same folder (the same bug/assumption as the contextmenu from http://www.codeproject.com/useritems/FileBrowser.asp has!).
It will actually assume that all files are in the folder of the last item you select (i.e. the focussed listviewitem)- this leads to different results depending on the way that you select all the files in Everything.


I have tested this using my own shell extension but it can also be reproduced with one I found on the internet called CopyFileNames (http://www.extrabit.com/copyfilenames/download/) which simply copies the selected filenames to the clipboard.

If you install this, search in Everything for a file found in many different directories, select them all, right click in Everything and click "Copy Filenames" then the list will be incomplete.

The reason it is incomplete is that CopyFileNames is getting paths, checking the files exist and removing ones that don't. Precisely the same happens with my extension.
As described above, the focussed item in Everything decides the incorrect path that the filenames get.
If you were to select from top to bottom in my above example, such that 21111.txt was selected last, then the results you should see from CopyFileNames is:
11111.txt
21111.txt
I.e. two of the passed file paths didn't exist in /2/ so were removed from the list.
If the first or third item in the Everything results were to have focus then the other two files would be returned instead.

If you use Explorer to perform the same search (Search for "*111.txt" but restrict to the parent folder because it's so slow!) then CopyFileNames and my extension both work correctly.


Thanks a lot, I love Everything and use it all day every day for all sorts of things! I love that it hooks my keyboard search key too

[therube]

I've seen that before too.

Was it here (if so, my searches are not finding it)?

Or was I thinking I had thought it was a bug on Nirsoft's end (& likely reported it to him) with his HashMyFiles utility.

Between Everything & Hash My Files, I can duplicate this.
HMF can bet set up as a Context Menu item, or you can simply drag two files into an opened HMF window.
Either way you will see the same results.

When I send two (Send To) files to Win32Pad from within Everything, it reports, "Can't open the file "C:\BIN\OLD\pagefile.sys C:\BIN\OLD\CONFIG.SYS"!".

BUT the two files I had selected were: C:\pagefile.sys & C:\BIN\OLD\CONFIG.SYS (& not C:\BIN\OLD\pagefile.sys).


EDIT: Ah yes, it was here ("tree" was the pertinent search term) that I reported it, in this thread: http://forum.voidtools.com/viewtopic.php?p=1150#p1150

[void]

I am aware of "Everything" opening some context menu items with the path of the focused item only, instead of the correct path for each file and folder.

I have fixed this for a few menu items, and will continue to fix other menu items..

If your application supports drag drop, you might like to try dragging your files from "Everything" and dropping on your application.