Page 1 of 1
Internal associations for files with intersecting filters
Posted: 2010-05-12, 13:52 UTC
by [Yustas.NeO]
wincmd.ini:
[searches]
uTorrent-files_SearchFor=*.torrent *.btsearch
uTorrent-files_SearchIn=
uTorrent-files_SearchText=
uTorrent-files_SearchFlags=0|000002000020||||||||22220|0000|
All files without folders_SearchFor=
All files without folders_SearchIn=
All files without folders_SearchText=
All files without folders_SearchFlags=0|000002000020||||||||22220|0000|
[Associations]
Filter1=>uTorrent-files
Filter1_Open with uTorrent="%COMMANDER_PATH%\..\uTorrent\uTorrent.exe" "%2"
Filter2=>All files without folders
Filter2_Open with AkelPad="%COMMANDER_PATH%\..\AkelPad\AkelPad.exe" "%2"
Menu by clicking Right Mouse Button
Now:
For *.torrent:
Open with uTorrent (Internal)
For all other files:
Open with AkelPad (Internal)
Suggest:
For *.torrent:
Open with uTorrent (Internal)
Open with AkelPad (Internal)
For all other files:
Open with AkelPad (Internal)
I apologize if this suggestion had already been.
Posted: 2010-05-12, 14:14 UTC
by MVV
Already suggested.
I support this, BTW I support also custom tooltip fields for all matched types.
Default action and icon should be taken from first match, but context menu items should be taken from all matched types.
Posted: 2014-03-14, 06:40 UTC
by MVV
ghisler(Author),
Christian, please add this feature to TC (at least optional), it will be very useful to combine context menu items for all matched templates. There are a lot of possible applications, one of them is implementing easy-to-use system to select WCX plugin to open specific file. If there are multiple items with same names, just show them all (mabe with template indicator in braces)...
Posted: 2014-03-14, 17:04 UTC
by ghisler(Author)
I tried to implement this when it was suggested because I would find it really useful too, but I encountered too many problems. Fir example, several filters could define the same command (e.g. "View"). Also currently TC has to remember just one extension which is used for all menu items.
Posted: 2014-03-14, 17:20 UTC
by MVV
As I said, you may display multiple items with same names, it is not your problem (almost any good function may be used incorrectly).
Why do you need to remember more than one extension? When building context menu, you need to check list of templates and add all items for all matched types, there is no need to remember anything...
Posted: 2014-03-16, 11:05 UTC
by ghisler(Author)
TC has to remember which filter was responsible for which menu item, because the filter determines the command line to be executed.
Another problem: Users who already have many such filters may be annoyed when they suddenly get a lot of additional lines.
Posted: 2014-03-16, 14:21 UTC
by MVV
Well, you really need to remember full information about all menu items (text, command), but you need this information anyway. I think it is much easier to put such information for all items into temporary array and then execute corresponding item just by index in this array.
Another problem: Users who already have many such filters may be annoyed when they suddenly get a lot of additional lines.
You should make this feature optional, turned on or off by default (don't know which one is better), so people who already have tons of items may leave this feature disabled.
Posted: 2014-03-25, 21:35 UTC
by fenix_productions
Maybe we could look on this "issue" from different view?
We may leave TC to build up menus as it is now but have associations manager which could help with overlapping filters, ie.
I choose XnView, define extensions, define command and click OK.
Then TC should:
1. check which parts of my filter may overlap with others
2. overlapping parts - combined as new filters which gather all applications falling into their rules,
3. non-overlapping parts - new filters limited to them only.
From TC UI perspective I would see filters for *.jpg, XnView, Photoshop, but INI file would contain:
Code: Select all
Filter1=*.jpg
Filter1_*.jpg=
Filter1_XnView=
Filter1_Photoshop=
...
Filter2=>Xnview/!*.jpg
...
Filter3=>Photoshop/!*.jpg
...
It would be more work from UI side but backend could stay the same.
Everything, of course, optional.
Posted: 2015-04-12, 07:45 UTC
by MVV
Would be great to have an option to merge internal associations' commands and custom fields' tooltips for multiple matching filters. Like it was suggested for
tooltips, same approach may be used for internal associations: every template that allows merging should have some 'merge' option enabled: e.g. a special '$merge' verb or a checkbox. So it will be compatible with old filters.
Posted: 2015-04-12, 15:47 UTC
by Balderstrom
ghisler(Author) wrote:I tried to implement this when it was suggested because I would find it really useful too, but I encountered too many problems. Fir example, several filters could define the same command (e.g. "View"). Also currently TC has to remember just one extension which is used for all menu items.
====================
Open [with Photoshop]
With -> IrfanView (View)
.......__ IrfanView (ThumbView)
.......__ XnView (View)
.......__ Photo (View)
.......__ SomeOtherProgram (Open)
.......__ YetAnotherProgram (Open)
======================
Additional filters would be displayed in a submenu. Handling duplicate "View" "Open", show them all in a sub-menu, and show the verb last in brackets.
Considering this is similar to how normal Windows (registry) associations would be displayed - multiple programs can be assigned, and are available in the normal context menu's "Open With" submenu. One might expect TC to be as functional (if not more so) than Windows built-in file extension association feature.
With many programs assigned to a given extension, and if said programs are given multiple association
verbs, it may make sense to add an additional option (or 2) for associations.
Eg.
========================
[x] Always Show for extension
.... (@) Show in Combined Sub-Menu
.... (_) Show in Separate Sub-Menu
.... (_) Show in Main Context Menu.
[_] Only Show for extension if:
.... [(0)]* other programs match.
=========================
* Edit field.