I've now tested the beta. Sorry for the delay mouser. I tested the portable version on a Windows 10 64bit PC.#filecontents
I confirm that the icon problem is now solved. Nice!
Aside: I know that FARR isn't unicode compatible, but it would be useful to remind users of that near #filecontents in the helpfile (and similarly for the fileresults command in helpfile). For the record, this is what happens with files with non-ANSI:
- If a .txt used with #filecontents has utf-8 encoding then non-ascii characters are garbled, as expected.
- If the .txt is utf-8 BOM encoded there is an additional issue, less expected: the lines/filepaths from from the .txt are shown in FARR (non-ascii characters still garbled) but the first item in the results list also has no icon. If I select that first item then the statusbar shows the filepath but with a prefix of 3 garbled letters. I suspect FARR is tripped up by the BOM part at the start of the file.fileresults
It works as expected in my small tests. For example this
appcap C:\test\test.exe ;;; fileresults C:\test\test.txt
where test.exe was a compiled AutoHotkey script that appends a line to the test.txt file
FileAppend, `ntesting, % A_ScriptDir "\test.txt"
Adding an extra sleep command also works
appcap C:\test\test.exe ;;; sleep 2000 ;;; fileresults C:\test\test.txt
I noticed also that the fileresults command skips all blank lines in the .txt file, which is good.
I'll post again later if I run into any issue when using the fileresults command in more complex aliases. But looking very good so far!appcapresults
I tested this very briefly. Worked when the application printed all of its output immediately in one go.
For example running ping.exe without parameters prints a few lines of help text in the cmd window. Those lines show up in FARR if we run this alias
But this on the other hand does not work
appcapresults ping.exe google.com
After a second an error popup shows with the text "Error: Access violation at address 00598228 in module 'FindAndRunRobot.exe'. Read of address 656D696C." Perhaps the problem is that ping.exe outputs lines incrementally as it gets results back from the ping and FARR's appcapresults expects the output all at once?
But perhaps this test is contrieved and unlike what the appcapresults was meant to do? I don't plan to use the appcapresults command myself so only tested with the first command line tool that came to mind. Anyway, might be good to handle that error somehow or warn in the helpfile against using apppcapresults with external tools that outputs lines incrementally (if that is the problem here).