Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.

You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.

FARR enables customization of the browser and/or file explorer used to "launch" URLs and files/folders respectively. This plugin generalizes this idea for files based on filename extensions.

The original motivation for this plugin was to enable one to make use of and transport file associations without getting involved with the registry -- e.g. for portable application types of settings -- well, at least for files launched via FARR

Usage

To customize the handling for a specific file extension, first ensure that FARR's "Program Options -> Lists -> User Variables" setting has an [Akete] section.

Then create a line in that section of the form:

<extension>=<executable-path>

where <extension> stands for the (typically 3-letter) file extension in question and <executable-path> is an appropriate path to an appropriate executable.

For example, to handle PDF files using SumatraPDF, one might use the following sort of text (assuming here that SumatraPDF.exe is the name of the executable and that it lives in D:\Apps\):

[Akete] pdf=D:\Apps\SumatraPDF.exe

If all goes well, FARR should now launch all files that end in '.pdf' using SumatraPDF.

If trying the Experimental version, please make sure to install the plugin in FARR's Plugins folder and name the folder for the plugin "Akete".

Akete - FARR-specific file associations

Introduction------------

The main point of this plugin is to be able to customize how files with particular file extensions are opened. To achieve this end, the user is expected to provide a configuration which specifies associations between file extensions and corresponding methods of opening files with those extensions.

Configuration details will be demonstrated through a series of examples.After each example a general rule will be stated possibly followed by some related notes.

Example 1

A configuration to get files with the extension 'txt' to be opened using Wordpad might be:

[Akete] txt=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe

Rule 1: <file-extension>=<path-to-executable>

Notes: The path to the executable may contain FARR Virtual Folder names (see the FARR help file). Also, file extensions do NOT contain the period character.

Example 2

A configuration to get files with the extension 'txt' to be opened by (possibly additional instances of) Notepad++ might be:

[Akete] txt=%PROGRAMFILES%\Notepad++\Notepad++ -multiInst "$$1"

Rule 2: <file-extension>=<launch-template-string>

Notes: The launch template string allows specification of command line arguments. The plugin replaces the string $$1 by the path to the file to be opened. Do NOT use the vertical bar character in a launch template string -- the reason for this should become clear below.

Once a file extension has been associated with a path or launch template string, it is possible to leverage this association so that any file specified via FARR's text edit field is opened using the associated path or launch template string.

For the examples above, if the text in FARR's text edit field looks like:

C:\boot.ini +withtxt

"launching" via FARR will open the file with path C:\boot.ini using Wordpad in the case of the first example, and Notepad++ in the case of the second example.

Notes: The keyword is assembled by prepending the file extension with the string "with" (the default keyword prefix string).

Example 3

A configuration to override the default keyword prefix string with the string "open" instead of "with", might be:

[Akete] Options.KeywordPrefix=open

Rule 3: Options.KeywordPrefix=<keyword-prefix-string>

Notes: The user variable name is the fixed string "Options.KeywordPrefix". The user variable value should probably be kept to a string composed of numbers and letters -- other values such as spaces, pluses, and the like are not likely to work. It may also be safer to not use uppercase letters in the user variable value.

Example 4

A configuration to get files with the extension 'doc' to be opened using whatever is configured for 'txt' might be:

[Akete] txt=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe doc=txt

Rule 4: <file-extension>=<file-extension>

Notes: For simplicity of configuration and implementation, if a file extension appears on the right hand side of an equals sign, it may not appear on the left hand side of the equals sign. Another way to phrase this is that only one level of indirection is supported.

Example 5

A configuration to get the context menu of a file with extension 'txt' to show context menu items for opening via Wordpad and Notepad++ might be:

Notes: The items in the list may be paths or launch string templates. The vertical bar character is reserved for separating the items so it may not be used in a path (doesn't tend to work in Windows anyway?) or a launch template string. Opening of files via FARR's text edit field will be handled using the first item in the list. It may be worth noticing that a single path or launch template string might be viewed as a list of one item.

A configuration to get the context menu of a file with extension 'txt' to show context menu items for opening via Wordpad and Notepad, but leaves handling of opening of such files untouched if done via FARR's text edit field might be:

Hi ewemoa. Good start . The plugin doesn't work as expected on my system though unless I assign something (anything, that is) to aliasstr. This reminded my of the problem I had when I was working on my (never released) OpenWith plugin. The onSearchBegins function was never called because I had left the default alias empty (because the plugin didn't need an alias). Maybe it's the same with onProcessTrigger?

Anyway, speaking of my never released OpenWith plugin. I think we've already concluded that the OpenWith plugin and your Akete plugin are similar. Maybe it would be a good idea to extend your Akete plugin to allow definition of "open with" keywords (using FARR's +keyword syntax) to launch files having the same file extension with different applications (what the OpenWith plugin does). I imagine something like this: [Akete] pdf=D:\Apps\SumatraPDF.exe OpenWithNpp=C:\Program Files\Notepad++\Notepad++.exe

and Akete not only launching .pdf files but also something like this: c:\My cool project\Config.xml +OpenWithNpp

I explained why I would like to have this functionality here by the way. The reason I never released the OpenWith plugin is that FARR keyword modifiers can't have spaces, i.e. something like +openwith=c:\program files\blah\blah.exe doesn't work. But by using defined keywords this would obviously not be a problem. With Akete doing this I could ditch the OpenWith plugin and would have something less to take care of

The plugin doesn't work as expected on my system though unless I assign something (anything, that is) to aliasstr.

Strange. What version of FARR are you using? I just tested it locally with 2.34.01 and it looks like it works for me without modification. Hmmm...

Quote

This reminded my of the problem I had when I was working on my (never released) OpenWith plugin. The onSearchBegins function was never called because I had left the default alias empty (because the plugin didn't need an alias). Maybe it's the same with onProcessTrigger?

Good question.

Quote

Anyway, speaking of my never released OpenWith plugin. I think we've already concluded that the OpenWith plugin and your Akete plugin are similar.

It is thanks to your generous sharing earlier that contributed to the birth of Akete

Quote

Maybe it would be a good idea to extend your Akete plugin to allow definition of "open with" keywords (using FARR's +keyword syntax) to launch files having the same file extension with different applications (what the OpenWith plugin does). I imagine something like this: [Akete] pdf=D:\Apps\SumatraPDF.exe OpenWithNpp=C:\Program Files\Notepad++\Notepad++.exe

and Akete not only launching .pdf files but also something like this: c:\My cool project\Config.xml +OpenWithNpp

I think I follow this suggestion. I intend to consider and experiment with trying to implement this. I have been wary of using keywords in FARR because I have experienced difficulties working with them. May be I can use this as an opportunity to improve my understanding.

I've thought about this a bit more and I think there may be at least one difficulty w.r.t. implementing the proposal. IIUC there isn't an easy way to programmatically enumerate the names of variables in User Variables (yet).

I suppose I could try to parse FARR's ini file, but I don't think I want to go that route.

Another possibility is to use a different form of configuration in User Variables. If all of the pairings of "OpenWith<X>", "<Path>" were stored in a different format -- e.g. as a kind of associative array under a single name -- then there would be no necessity of determining variable names because there would only be one hard-wired one. I believe czb has applied this method in at least one (may be two or more) of his plugins -- through the use of JSON. One potential drawback to this approach is that editing of User Variables becomes much more complex.

Upon further reflection on the matter though, I think it is the case that enumeration may not be necessary. If the plugin can access the current set of keywords (which I believe it can via Search.keywords), it can attempt to access User Variables of specific names based on the set.

Below is an initial implementation -- all that is needed to try it is to replace the content of the existing fscript.js. Ah, and depending on one's environment, perhaps it is necessary to fill in aliasstr (still don't know what the issue is with that).

I was surprised to see that retrieving keywords via Search.keywords seems to give lowercased keywords. Consequently, it looks like it's currently easier to use "openwith<string>" (all in lowercase) inside User Variables -- in fact, the current Akete code assumes this.

Formatted for Javascript with the GeSHI Syntax Highlighter [copy or print]

Works perfectly! Even with an empty aliasstr now which is really strange.

Concerning parsing FARR's ini file: I agree that it's probably not a good idea. I am nevertheless doing it currently in my never released Windows Search plugin to query the max. entries to display values. It would really be good to have an officially supported way to query some FARR settings (sorry, just wanted to use this chance to repeat that yet again )

It's confusing to have the download in the first link and also attached..Maybe best is to always update the one linked to in the first post, and then later on in the thread you can always just say:"download the latest from the link in the first thread" instead of attaching?

This is a great idea, but from my point of view there are two things that keep it from being useful when run from a USB stick. (At least from the description. I haven't tried it out yet. The last time I played around with anything on my stick, I was very, very sorry.) First, I'd like to see a simple way to turn it on and off, so when I wanted to use my own machine's associations, I could. (I do this when setting up a stick on my machine to keep the programs on it from running, so I get less reads / writes to the stick.) Second, I'd like to see a way to specify the relative path from the root without needing to specify a drive letter. After all, if I have to use my stick on another machine, I have no idea what letter it will be assigned - and if I'm doing that, nine times out of ten I'm in no mood to go in and change a bunch of settings right then.

Two other nice features would help out, a lot. One would be a chance to specify two options, by keyword, such as Open and Edit. I think the point there should be pretty clear. The other one is a workaround for a particular program I use, Liquid Story Binder XE. It is a great writing program, but it has one quirk. All files are arranged in a "library" by "book" - each book is a folder under one user-specified folder for the library. Each book actually contains a whole set of files. So, to open a "book" in LSB, you have to run LSB with the book's folder specified in the command line or shortcut. Is there any way to let the user specify such behaviour? (Open X app with the path of the selected file specified, but strip away the filename...)

First, I'd like to see a simple way to turn it on and off, so when I wanted to use my own machine's associations, I could.

I have an idea or two about this -- I intend to figure out whether they are practical.

Quote

Two other nice features would help out, a lot. One would be a chance to specify two options, by keyword, such as Open and Edit. I think the point there should be pretty clear.

If it doesn't have to be by keyword, there is already a way to specify multiple paths for each file extension -- this information is used in augmenting the context menu for a search result by a context menu item per path (you end up seeing something like "Open with myapp.exe" for each path). I think I documented this feature in the README.txt of the plugin, but I don't recall at the moment.

Quote

The other one is a workaround for a particular program I use, Liquid Story Binder XE. It is a great writing program, but it has one quirk. All files are arranged in a "library" by "book" - each book is a folder under one user-specified folder for the library. Each book actually contains a whole set of files. So, to open a "book" in LSB, you have to run LSB with the book's folder specified in the command line or shortcut. Is there any way to let the user specify such behaviour? (Open X app with the path of the selected file specified, but strip away the filename...)

Currently, this is not supported. mouser made a similar suggestion and we have discussed the possibility of support for something like what one can specify for an alias string. So for example, you might be able to express something like:

%PROGRAMFILES%\Something\Another.exe /p /e "$$1"

and $$1 would get filled in with the file identified via FARR and %PROGRAMFILES% would get resolved to the relevant path.

I am drafting some documentation for a newer version and thinking that it may act as a specification. This post should contain my first attempt. Feedback is welcome

Introduction ------------

The main point of this plugin is to be able to customize how files with particular file extensions are opened. To achieve this end, the user is expected to provide a configuration which specifies associations between file extensions and corresponding methods of opening files with those extensions.

Configuration details will be demonstrated through a series of examples. After each example a general rule will be stated possibly followed by some related notes.

Example 1

A configuration to get files with the extension 'txt' to be opened using Wordpad might be:

[Akete] txt=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe

Rule 1: <file-extension>=<path-to-executable>

Notes: The path to the executable may contain FARR Virtual Folder names (see the FARR help file). Also, file extensions do NOT contain the period character.

Example 2

A configuration to get files with the extension 'txt' to be opened by (possibly additional instances of) Notepad++ might be:

[Akete] txt=%PROGRAMFILES%\Notepad++\Notepad++ -multiInst "$$1"

Rule 2: <file-extension>=<launch-template-string>

Notes: The launch template string allows specification of command line arguments. The plugin replaces the string $$1 by the path to the file to be opened. Do NOT use the vertical bar character in a launch template string -- the reason for this should become clear below.

Example 3

A configuration to get files with the extension 'doc' to be opened using whatever is configured for 'txt' might be:

[Akete] txt=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe doc=txt

Rule 3: <file-extension>=<file-extension>

Notes: For simplicity of configuration and implementation, if a file extension appears on the right hand side of an equals sign, it may not appear on the left hand side of the equals sign. Another way to phrase this is that only one level of indirection is supported.

Example 4

A configuration to get the context menu of a file with extension 'txt' to show context menu items for opening via Wordpad and Notepad++ might be:

Notes: The items in the list may be paths or launch string templates. The vertical bar character is reserved for separating the items so it may not be used in a path (doesn't tend to work in Windows anyway?) or a launch template string. Opening of files via FARR's text edit field will be handled using the first item in the list.

A configuration to get the context menu of a file with extension 'txt' to show context menu items for opening via Wordpad and Notepad, but leaves handling of opening of such files untouched if done via FARR's text edit field might be:

Notes: One can think of the asterisk character as similar to a wildcard pattern character.

Example 6

A configuration to get the plugin to recognize a keyword to override opening behavior for opening a particular file via FARR's text edit field might be:

[Akete] openwithnpp=%PROGRAMFILES%\Notepad++\Notepad++.exe

Subsequently, specifying a file along with the 'openwithnpp' keyword in FARR's text edit field (and "launching" for example, by pressing the Enter key) should lead to an attempt to open the specified file using Notepad++.exe. The contents of the text edit field might look like:

C:\boot.ini +openwithnpp

Rule 6: openwith<string>=<path-or-launch-template-string>

In summary, there are three types of user variable names (strings to the left of the equals sign) that may be specified:

1) file extension 2) string of the form openwith<some-string> 3) *

and two types of user variable values (strings to the right of the equals sign) that may be specified:

Thanks for taking the time and making the effort to read the draft -- I really appreciate it!

As to the keywords that begin with "openwith", I chose this based on phitsc's example and am not particularly attached to it -- except that if it's changed, I guess trying to maintain backward compatibility might be something to consider.

Oh no, don't say we should be able to configure what the keyword starts with via FARR User Variables!

As to the keywords that begin with "openwith", I chose this based on phitsc's example and am not particularly attached to it -- except that if it's changed, I guess trying to maintain backward compatibility might be something to consider.

And neither am I. Wouldn't give me a lot of work if you changed it. I'm no big fan of abbreviations though, so I still think openwithnpp would be clearer than something like e.g. ownpp.

What about just using the same definition as used for extensions, e.g. if one specified something like:

txt=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe

then it would open .txt files with Wordpad, but one could also do this:

C:\boot.ini +txt

and it would also open with Wordpad.

I could then choose whatever definition I liked (even openwithnpp ) and since there are no files with an extension of .openwithnpp it would just work with this C:\boot.ini +openwithnpp. You would have to check if it might give problems with other keywords though.

Thank you phitsc, for also taking the time and making the effort to read the draft and comment on it

The idea you suggested sounds interesting. As you pointed out, there does seem to be a potential issue with keyword collision and I am mulling over what might be done about that. Perhaps allowing a configurable prefix (which defaults to something) for the keyword and reusing the definitions from file extensions as you suggested might work out.

My impression at the moment is that having a particular prefix helps in picking out an appropriate keyword from the query. Supposing that there is no particular prefix string for the keywords this plugin should handle, if a query contains multiple keywords, I am not sure how to decide which keyword (possibly multiple?) should be selected by the plugin.

Regarding a default keyword prefix, "open" or "with" seem like possibilities to me.

I think I'll go with a default of "with" as the prefix, provide a way to change the prefix, and leverage any existing file extension association configuration so that it may be used with a keyword (e.g. if you have an association defined for 'html', then the plugin should recognize the keyword 'withhtml').

I discovered that one can use period-separated names for both section names (e.g. "Akete.Options") and variable names (e.g. "Options.KeywordPrefix") in FARR User Variables. Also, that:

[Akete.Options] KeywordPrefix=test

ends up being the same (?) as (at least as far as requesting the value from FARR is concerned):

[Akete] Options.KeywordPrefix=test

I'm currently leaning toward suggesting the use of the variable names in the official documentation.