topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Friday March 29, 2024, 2:58 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Last post Author Topic: #filecontents FILEPATH -- how does it work?  (Read 20146 times)

Nod5

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,169
    • View Profile
    • Donate to Member
Re: #filecontents FILEPATH -- how does it work?
« Reply #25 on: February 18, 2019, 04:04 PM »
I'll have time to test the beta later this week.

Nod5

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,169
    • View Profile
    • Donate to Member
Re: #filecontents FILEPATH -- how does it work?
« Reply #26 on: March 06, 2019, 04:17 PM »
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
appcapresults ping.exe

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).
« Last Edit: March 07, 2019, 03:05 AM by Nod5 »

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: #filecontents FILEPATH -- how does it work?
« Reply #27 on: March 08, 2019, 07:58 AM »
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?

Sounds like a bug.. FARR should be fine with a commandline tool that does not output it's contents all at once -- I think..  Either way it's a bug that it throws that error..

Actually let me revise that, the function to display the results of a commandline tool as text in memo mode should be happy to have the results come in slowly from a continually running commandline tool.. but the new function to grab output as results may not be nearly so happy to do so :)