requests: silent reload .alias files + obey alias file disabled/enabled status

[Nod5]

Request 1: add a method to silently reload all aliases from .alias files

Request 2: add a FARR alias reload method that also updates the disabled/enabled status for each alias based on if it has the Disabled element in the .alias file.

These changes would enable users to script changes directly to .alias files and then quickly and silently apply them.

Background
The FARR special search string "goareload" reloads/updates aliases from .alias files. But not silently since after the reload it forces the "agroups" command that show all aliases as a list in FARR results. For request 1 make a new special search string "goareload_silent" that differ only in that it does not force "agroups".

The least visible workaround I've found to reload aliases from file:
1. FindAndRunRobot.exe -search goareload
2. FindAndRunRobot.exe -hide
But the FARR window still flickers briefly and sometimes the -hide command fail when scripting these steps (timing issues)

Edit
We can also reload aliases from file with the exit and restart method:
1. FindAndRunRobot.exe -exit
2. script changes to .alias file
3. FindAndRunRobot.exe -hide
Advantage over "goareload": No results window flickering. Drawback: FARR restart can make this method slower.
Edit end

Request 2 is because FARR's "goareload" command ignores "<Disabled>" elements in the .alias files. Disabled/enabled status is instead ruled by the FindAndRunRobot.ini line DisabledAliasStrings . In other words having a script add the line "<Disabled>true</Disabled>" to an .alias file AliasEntry section has no effect even though all other changes to .alias file elements are applied by "goareload".

The least visible workaround I've found to modify Disabled/Enabled status of aliases:
1. FindAndRunRobot.exe -exit
2. have a script read, modify and overwrite the string for DisabledAliasStrings in FindAndRunRobot.ini
3. FindAndRunRobot.exe -hide

But that can take several seconds and is sensitive to timing issues.

Request 2 could be done as a separate special search string. Or a FARR setting to toggle authority over disabled/enabled status between .ini and .alias files. Or a combo special search string that for both request 1 and 2, e.g. "goareload_silent_alsodisabledstatus".

[Nod5]

After some more tests and a better test script this method actually is consistently quite fast:

1. exit FARR: FindAndRunRobot.exe -exit
2. edit .alias / .ini
3. start FARR: FindAndRunRobot.exe -hide

Takes less than a second with the right script. The requested features would still be nice to have though, but this workaround is reliable enough for use in scripts. So I've now made a replacement FARR alias editor prototype that starts off with the filter_alias script. Will test it some more and release later if good enough.

The improvements are alias filtering, sorting the alias list and, the big one, being able to use FARR while editing FARR aliases.

[mouser]

Sorry for the late reply.

I'm pretty sure there is a commandline call for FARR specifically to tell it to reload it's alias files.  It was made for the exact purpose you are talking about -- if an alias file is edited outside of FARR while it's running, you need to tell it to reload the alias files.
But I don't see it in help file in the Commandline Options help page..

It looks like there is a special command you can type in FARR: goareload (reload all aliases), so you could call farr commandline and tell it to run that.

But I will add a proper commandline to do it.


Now as for reloading the INI file.. that might be trickier without existing and restarting FARR, but I might be able to add a commandline option to tell it to do that.

[Nod5]

goareload (reload all aliases), so you could call farr commandline and tell it to run that.

Yes, but even when we run that on the command line like this "FindAndRunRobot.exe -search goareload" FARR afterwards forces a load of the additional search string "agroups" which lists all aliases in the results window. So it isn't silent. It would make sense to change "goareload" to not do that extra step since users can already call "agroup" separately if they want it.

Now as for reloading the INI file.. that might be trickier without existing and restarting FARR, but I might be able to add a commandline option to tell it to do that.

Or a command to reload aliases and read .alias <Disabled> elements and use the read data to overwrite the Disabled/Enabled status in FARR's working memory (assuming FARR doesn't read from ini to memory each time options open). Then on FARR shutdown (or whenever it writes to .ini) the data would have passed from .alias to memory to .ini.

Whichever is least work I suppose. And if both ways would take much work then do neither. I mean this is a niche use case and now that I figured out how to script the shutdown/edit/restart steps quickly and reliably the extra benefit of doing it "restartless" would be small.

In fact if you only have one chunk of time to spend on any of this consider instead making FARR work while options are open (specifically the Edit Group Alias window). I simply cannot be the only one tripped up by that time and time again. That was the main reason I wanted to code my own alternative FARR alias editor. You know, it takes a special kind of evil genius to make a program so intuitive, great, useful and versatile as FARR, a program that users quickly learn to use all the time and extend through the powerful alias features to become almost like an extension of your thinking that you trust can be used while in any and all programs... except its own options! Cruelty! A bit like making the best car in the world that can drive absolutely anywhere... except into its own garage. There you have to get out and push it. (All this said tongue in cheek of course. FARR is great!  )