« on: June 01, 2007, 05:15 AM »
That's so funny - I just wrote something almost exactly the same (although I hadn't spotted that you can use RegEx as an argument to SetTitleMatchMode ... so mine was case sensitive.
I must admit - I think there could be a lot of mileage of Skrommel and Mouser teamed up and put the AHK script engine inside FARR - or alternatively ...
Mouser - are you listening? - had a way of getting any scripts/executable to contribute to the list of things that you can pick from. I'm a Mac user at home and power of QuickSilver is that there are so many plug-ins for it - and they're generally reasonably quite straightforward to make in AppleScript ... so I was thinking ...
It would be great to enhance the alias function a little bit - so that you could have two types of alias - one as per the existing alias - and a new type of alias - that can contribute to the result list. For example:
1. You set up this new type of alias and when FARR matches that alias (e.g. "+killpid") - it calls an executable that you define -
1000>>>Kill PID>->C:\Program Files\FindAndRunRobot\Scripts\GenerateKillPID>+>killpid (.*)
That executable runs (and say for example gets the list of windows names) and passes back a string (delimited by ||) along the lines of the following:
Kill Notepad, 1000, c:\program files\scripts\killpid 1021 || Kill Outlook, 1000, c:\program files\scripts\killpid 998 || Kill Firefox, 1100, c:\program files\scripts\killpid 521
3. FARR then displays the "friendly name" in the list, i.e. "Kill Notepad" along with a weighting that can be put with the rest of the results, then the string that FARR executes if that option is chosen.
I think this would be relatively easy to implement (although I'm not volunteering to do it, Mouser), not be too unperformant (since FARR would only execute GenerateKillPID when it matches the alias and allow FARR to be really expandable without too much bloat.
What does everyone think?