alternative (portable) file associations

[cspot]

total commander is the central tool of my portable application collection.
one thing that is currently not portable are the windows file associations.

my idea is to implement optional TC specific (and windows independent) associations. I would like use relative paths based on %COMMANDER_PATH% (like I set IViewPath=%COMMANDER_PATH%\..\..\media\image\iview40\i_view32.exe. same thing with button bar).

regards,
cspot

[Lefteous]

It has already been suggested but it's always a good idea to renew the request

http://www.ghisler.ch/wiki/index.php?title=Open_files_by_filetype

[cspot]

great, good to know I'm not alone with my wish

[ghisler(Author)]

I'm considering it, but it would be conflicting a lot with normal associations.

Currently you can use either the button bar with %P%N parameter to create one button per editor you have on the stick, or use the Alt+F3 external viewer for it. Here you can define a different viewer per file extesion.

[m^2]

I'm considering it, but it would be conflicting a lot with normal associations.

That's what it's meant to.

Currently you can use either the button bar with %P%N parameter to create one button per editor you have on the stick, or use the Alt+F3 external viewer for it. Here you can define a different viewer per file extesion.

No, that's a very bad solution, too many things to remember. The best solution are programs like OpenFileTC or F4 menu, but they are worse than internal associations because they rule out mouse centric users and return is definitely the most natural and comfortable hotkey.

[cspot]

I'm considering it, but it would be conflicting a lot with normal associations.

could you explain this conflict?

I would suggest the following algorithm:
local associations are optional, if a local association exists it overrides windows association (inside TC of course..)

this is an easy definition and it is useful for portable scenarios.

regards,
cspot

[solid]

I would suggest the following algorithm:
local associations are optional, if a local association exists it overrides windows association (inside TC of course..)

Yes, that's the way to go.
Support++

[roentgen]

How about something like cm_switch_assoc_order with various states:

1. only tc associations.
2. tc assoc prevailing over windows ones.
3. tc assoc if windows doesn't have any.
4. normal windows assoc.

[Horst.Epp]

I use CAFE Mod for this purpose.
http://portableapps.com/node/13453

You can make assocations depending on classes.
So I have several assocations for extensin if double clicked from Total Commander for example.

[m^2]

CAFE works only with double clicks, not with return.
It is a solution, but as poor as other ones.

[Lefteous]

2ghisler(Author)

I'm considering it, but it would be conflicting a lot with normal associations.

I don't see a problem here. As I described in my wiki article TC associations would just _overrule_ Windows associations. This approach is comparable to "define colors by filetype". In this function the first matching filetype is colored. If none match use the defined text color.
It could be discussed if this has to be an option or just work like this. I could't find any disadvantages in such a fallback behavior.

[Hacker]

Christian,
I suggest using Enter to "run" a file using one association system and Shift-Enter to "run" it using the other one. It already works like this for archives. And you can introduce one simple switch like:

Code: Select all

[x] Use internal associations by default

that would toggle Enter / Shift-Enter behavior between internal (TC) and external (Windows) associations.

Roman

[fenix_productions]

2Hacker
Nice idea but there should be additional cm_XXX command for making it more customizable.

The only thing that makes me worry are the archives. You could be always "one assoc less" for the types treated like directories.

Let's see two imaginary cases...
In my portable TC I've got CHM and ISO plugins. The first one is not treated like directory (no box icon) and the second one is.

Case 1: CHM
Ctrl+PgDn -> browse,
Shfit+Enter -> loads TC's assigned app,
Enter -> loads system's CHM viewer,


Case 2: ISO
Ctrl+PgDn -> browse,
Shfit+Enter -> loads TC's assigned app,
Enter -> should it load Windows' app or browse?

If you switch the keys (Enter for system's association) then there is still the problem with Enter key. If you decide to browse then one association is missing. If you have system's call then... no browsing.

[Lefteous]

I thought a bit more on this and I think there are basically 3 meaningful ways to open a document in an application:

• Open the document using a default application. Executing this command will just open the document in the default application.
• Open a document in an alternative application. In this case a list of applications should be displayed in a popup menu. The user can choose an applications of his choice.
• Open a document in "plain" mode. This is the classic "F4" command. In this case an editor is opened which detects the type of document (plain text, formatted text or binary) and displays the file in an appropriate view.

These commands should be available in TC.

There are already some nice external programs which work in a similar way as the 2nd command. I would prefer an internal implementation which is based on an internal association system.

Of course all this commands should work with multiple documents. MDI (multiple documents in a single instance) and SDI applications (one document per instance) must be supported.

I will extend my article in our wiki. The update will include the new considerations.

[cspot]

@all
thank you for your contributions. Good to know that this topic is of interest.

@ghisler(Author)
christian,

could you please give us an update of your considerations.
I would be glad to see this feature beeing implemented

thank you,
cspot