DonationCoder.com Software > Find And Run Robot

Folder Modifier Bug?

(1/3) > >>

JohnJ:
There appears to be a bug in launching certain filetypes using an alias (in this case files with an '.ahk' extension) when a folder modifier is used instead of the direct file path in the result box. Here is a simple example that fails for autohotkey '.ahk' files:

I create two simple alias: the first uses the autohotkey path directly and the second uses a defined folder modifier 'ahk' that has that same path

1. alias: 'ahk1'
    regex: ^ahk1 (.*)$
    result box: ahk1 $$1 | dosearch c:\autohotkey\ $$1

2. alias: 'ahk2'
    regex: ^ahk2 (.*)$
    result box: ahk2 $$1 | dosearch +ahk $$1
The folder modifier 'ahk' is defined simply as the same directory used in 1) above: i.e., an ahk modifier definition for directory: c:\autohotkey

When I use the above formats for normal files, e.g., .exe, .lnk etc. the above two formats perform identically and work correctly. But for the above ahk example case 2, the search acts normally and finds the correct file and that file will launch correctly if I launch it from the context menu. But if I hit enter or try to double click on the found result a new search simply occurs and i only see 'Searching c:\ ...' and the file does not launch. This only happens in the case of the .ahk extension. All normal extensions work perfectly. I tried every possible launch option and the error still occurred.

It appears that in the case of an unrecognized extension (here 'ahk') the launch routine, only when a modifier is used, gets confused with that unrecognized extension. I am using x64 Win 8.1 and have associated the .ahk extension with autohotkey and, as I said above, the launch works fine as long as I use the path itself in the alias result box instead of the folder modifier +ahk.

I also tried creating a separate folder and add shortcuts (.lnk) to the '.ahk' files and then tried version 2 above using a modifier; those shortcuts worked fine. There was no problem with FARR recognizing the .lnk file to the .ahk file and then correctly launching the .ahk file when I used a folder modifier to that lnk directory.

For the time being I am simply using that second .lnk directory to launch .ahk files. Incidentally, this appears to be a good technique to quickly create multiple 'alias' names for a single file since the shortcuts can each be differently named. If you create a new folder modifier to that shortcut folder, those new alternate file ('alias') shortcuts can then be used to access the same file using multiple aliases ... very convenient!.

mouser:
Welcome to the site, John.

Very clear description of what certainly seems like a bug.

It always makes me happy to see people using some of the more unusual features of the program  :Thmbsup:

To make sure I follow: The first alias works in all cases.. the second alias fails when you use Enter or double-click to launch .ahk files.  Correct?

JohnJ:
Mouser: Correct.

Actually, as I stated, that bug led me to a solution (use shortcuts as multiple alias) that solved another problem that frustrated me with FARR. I was always a happy user of Keybreeze because it has a simple and effective alias interface (and way to keep track of the aliases) where every link was located only through its alias. This allowed me to create effective variations on file names (to access to the many tasks I do repetitively) via the use of creative aliases resulting in only 3 or 4 easy to remember keystrokes for my common tasks. FARR appeared to have that potential but presents a more complex interface so I never could quickly duplicate what I was doing in Keybreeze. For example, actually viewing and editing all aliases I create in FARR is more challenging and the scoring method is powerful but can lead to hard to track reasons why certain results occur. In short, it requires more effort on my part! This is not a criticism but only an observation of the pros and cons of a more powerful system.

Discovering the technique of simply placing shortcuts to my common tasks in a single folder and naming them in the same manner I was using in Keybreeze quickly duplicated what I liked about Keybreeze so much. Unfortunately, with the latest release in Win 8.1, Keybreeze is forever 'broken' and appears to be moribund which is why I turned to your great program. The work-around fixes I came up with, i.e., use the path directly not a modifier, and use a shortcut folder, makes the bug effectively irrelevant and/or easy to work around in the rare cases it appears with some unrecognized extensions.

mouser:
Nice (I'll still fix that bug you found).

Your comments about the difficulty in simple management of user aliases are on point -- it is something that could and should definitely be made easier.

mouser:
John,

I was just talking to someone who wanted to be able to add a quick secondary alias for an existing built-in alias.  So for example instead of typing "search" to trigger the search alias, they want to just be able to type "s".

When thinking about their request and your points above, I wondered about creating a new tab called something like "Quick and Easy Aliases" or something like that.

It would be a tab with one big text box, and some instructions, and you would just use it to specify quick easy aliases like:
"s search
"ff firefox.exe"

It wouldn't have a list of items to click to edit in a separate dialog -- it would just be one large text box, only suitable for quick and dirty specification of simple "aliases".

I wonder if you have any thoughts on whether that would help make it easier for people to quickly add simple common search aliases, etc.

Navigation

[0] Message Index

[#] Next page