Everything, filelist .efu, cannot {exec} > 1 item ?

[therube]

(Kind of resolved, but I'll go on...)


Everything, filelist, .efu, cannot {exec} > 1 item ?


if you open an .efu
if you highlight more then 1 file
& hit <Enter>
nothing happens
as in nothing is {exec'd}

so if your .efu has
1.txt
2.txt
3.txt

& you highlight 1.txt & hit <Enter>, 1.txt opens in your text editor
& if you highlight 1.txt & 2.txt & hit <Enter>, nothing happens ?

Code: Select all

COMMAND 41000
no menu 8

(the no menu 8 is not always constant, as i've seen other numbers too,
mostly single digit, but then this also, no menu 3335944)

& while messing with that...

Code: Select all

Description:
  A problem caused this program to stop interacting with Windows.

Problem signature:
  Problem Event Name:	AppHangXProcB1
  Application Name:	Everything.exe
  Application Version:	1.5.0.1383
  Application Timestamp:	666fbb8a
  Hang Signature:	f460
  Hang Type:	129
  Waiting on Application Name:	conhost.exe
  Waiting on Application Version:	0.0.0.0
  OS Version:	6.1.7601.2.1.0.256.1
  Locale ID:	1033
  Additional Hang Signature 1:	f460cf12b0300546c807cc53ed55034f
  Additional Hang Signature 2:	4e80
  Additional Hang Signature 3:	4e805644a98950695069fb9e3e97471c
  Additional Hang Signature 4:	89cb
  Additional Hang Signature 5:	89cbda33cfdf8171ed8a20fafbc05bda
  Additional Hang Signature 6:	c303
  Additional Hang Signature 7:	c303e47e1070d8d8d11cc001be74a902

conhost.exe.

as it is i started, "ran", the .efu
from a command prompt, cmd.exe
started a fortnight ago
(Everything itself had probably been running since 1383 came out)
by running, "filename.efu" <Enter>
(also had Debug Console open [which stopped debugging when Everything hung ])
(closing that console window made no difference)
(should have captured the crash, cause i'm now not dup'ing the issue...)
(& while we're on {exec}, i probably, finally, ought to get around to Sandboxie... but I'll wait... heh)
(& while we're at that... go back & read post about .efu... -> see, Everything, Filelist, .efu)

• a Filelist is a STATIC /representation/ of a /list/ of files
  it is NOT a LIVE /directory/ of files
  in that respect, a wanted action, like a DEL, is taken on a /representation/, a /list/
  & NOT on a "file"
  
  & as there is no CONCEPT of a DEL of a (filename on a) /list/ - you CAN'T
  do said action, DEL
  
  - but, you can open the actual /directory/ where the file resides,
  & DEL the (actual) /file/ from within the directory in that manner...

(& then this also relates to the F5/Refresh request of the filelist <thread>

• Everything Filelist - Refresh

+ so any functions/actions allowed on a "filelist", like a single file {exec}, are specifically allowed,
done - by Everything, as there is no concept of a "Windows" action that can be taken on a "filelist")
hmmm...
(not being able to do more then 1 simultaneous {exec} seems like a big limitation
& at that point, i might as well just do a... ?)

now, if you have a list of file names & use the filelist: function (is it)
instead of a filelist .efu, that filelist: is "live" & all normal functions/actions do apply

so, can you automate a list of filenames, names stored in a file, like, heh, an exported text
file, -export-txt, & have that load as a filelist: ?

OK, so that is exactly what, -search-file-list, does

now, that begs the question,
why a (static) filelist (.efu) over a (live) -search-file-list (filelist:)
or vice-versa?

so if you "open" a .efu, you're static,
if you -search-file-list a .efu, you're live (& the same .efu works for both)
(likewise, you could change the Window Registry association for .efu from -filelist to -search-file-list [but i'd think one would not want to do that])

OK, so then efuL.bat would do it (open .efu[Live])

& then the problem becomes that you're then dealing with fullfilenames
& so your search itself is essentially static, so if you rename a file
that new name no longer matches the search, so it drops from the list... hmm... seem to recall something about that... OK

so... at that point, if the es search returned what was needed
then simply a matter of doing the same search but with the GUI instead
(& so long as the search is "broad enough", that the renamed file still meets the search, then it will not drop from the list)
hmm... OK

& if we save the search string in an Environment Variable
then we can simply pass that same (variable to a) batch file...
AND, i already do that, as it is, so all i need to do is read it!

[void]

Everything, filelist, .efu, cannot {exec} > 1 item ?

Disabling Tools -> Options -> Advanced -> context_menu_shell_extensions will cause this issue.
I am working on a fix.

A problem caused this program to stop interacting with Windows.

The most common issue is the console was put in mark mode.
Clicking on the console will put it in mark mode.
Right click to exit mark mode.

[therube]

the console was put in mark mode

I take it that that applies to Win10+ ?
(Win7 here.)


Look at that. Still a time (granted a decade ago) when "MS" could actually put out a meaningful, well written article:
Console Improvements in the Windows 10 Technical Preview
(Alas, that ship has sailed.)

[void]

Any windows version.
Enabling quick edit makes it easier to enter mark mode.
I don't think it was mark mode at this stage because closing the console would terminate Everything.
Everything would hang when trying to write to the console if the console process was also hung.