Tooltips show plugin hints only for first extenstions set match

[DrShark]

To reproduce:
1. Create 2 extensions sets for hints in tooltips using plugin fields:
go to Configuration, Display, enable, "Show filename in filelist in tooltip if truncated", then "Win32-style tips with file comments (if available)", then using User-desined: [+] button add 2 sets of extensions with 1 (any) plugin field for each.
For example, in a first set add * as extension, add File name: [=tc.fullname] as a plugin field. Then add *.ext as extension, and add File extension: [=tc.ext]. So in "Custom fields by file type" there will be 2 lines (extensions sets):
*.ext
*
Confirm everything now in configuration windows.
2. In filelist, create a file with .ext extension, move mouse cursor on it: even though "ext" matches both *.ext and * masks, in tooltip you'll only see a hint defined for *.ext. If then in "Custom fields by file type" to move * above *.ext, TC will only show hint defined for *

Expected behavior: hints for all matching extensions sets should be shown in a tooltip.

[petermad]

I think this is more of a missing feature than a bug.

[ghisler(Author)]

This is intentional like with internal associations. You can add everything you want to see to a specific extension, or use multiple extensions for the same option.

[MVV]

It was requested many times, for tooltips and for internal associations, but still not realized (sad). It is much easier to allow once than to set up a matrix of presets for intersections of different file types.

E.g. I want to have a big preset for all image files, and one for all archives, and one for all files that have hardlinks, and of course I want to be able to edit any file as Administrator...
One have to copy-paste all cross-preset items to all presets where he wants to have them, and then he needs to modify all copy-pasted items when item modification is needed...
As I result, people just don't get from TC all what they could get from it, because maintaining such things is too boring.

There would be no harm in optional merging different presets, except maybe performance (because TC would need to scan entire list, but it is not a problem because it is a rare action), but it would improve usability a lot. You could add a flag for preset if it may be merged with others...

[ghisler(Author)]

I have added it for internal association as an option, but had to remove all additions and release TC 9.22 because of the unace error. for associations, it will only add extra verbs to the context menu, though.

[MVV]

I agree that 9.22 was mostly a security hotfix.

I'm looking forward to the new version with this addition:) but merging would be appreciated for tooltips too, because there are cases when it is required. E.g. I show NTLinks' real path for every file/folder and symlink/junction target for symlinks, but I also want to have some exclusive fields for specific file types.

[petermad]

This feature is now introduced in TC 9.5b1

[MVV]

Yes, finally, and it is great!

[DrShark]

I have tried it now on my configuration in TC 9.50 beta 3.
In context menu of a file in normal file system, the context menu has all the items of all matching patterns (extensions sets defined in Internal Associations).
In archive, however, in file context menu there are only matching menu items of extensions set which is higher in Internal Associations dialog.
In other words, for example, if in Internal Associations we'll define some context menu items for *.* pattern, and some other context menu items for *.pdf pattern, in a context menu of pdf file in archive TC will show only menu items of a pattern which is higher in Internal Association dialog.

[petermad]

In archive, however, in file context menu there are only matching menu items of extensions set which is higher in Internal Associations dialog.

Confirmed in TC 9.5b3

[DrShark]

05.11.19 Fixed: Right click context menu on file in archive didn't support verbs from multiple internal associations (32/64)

It seems on my system this fix makes TC hang if to try a context menu (even internal, e.g. using a command cm_ContextMenuInternal). Here it hangs on try to call a context menu for *.pdf even in regular file system now. Case related entries of [Associations] section from wincmd.ini:

Code: Select all

[Associations]
Filter1=*.pdf
Filter1_open=cmdmin.lnk  /c start "" /MAX acrord32.exe /a zoom=100 "%1"
Filter1.icon=%programfiles%\Adobe\Reader 10.0\Reader\AcroRd32.exe
Filter1_AcroRd32 (100% &scale)=acrord32 /a zoom=100 "%1"
Filter2=*.*
Filter2_NTFS Streams=**stream

I also just sent email with WhatIsHang tool report of a hang event to support email, the mail subject:
TC 9.50b4: internal context menu hang after a fix for multiple verbs

[petermad]

It seems on my system this fix makes TC hang if to try a context menu

Same here. See: viewtopic.php?f=32&t=54621

[ghisler(Author)]

Confirmed, thanks. I moved a "catch all" entry with wildcards *.* near the top of my list for debugging, so I didn't notice the problem.

[DrShark]

Confirmed, thanks. I moved a "catch all" entry with wildcards *.* near the top of my list for debugging, so I didn't notice the problem.

08.11.19 Fixed: Context menu hanging when using internal associations with option "Load extra commands from all matching types" and one of the "open" commands wasn't * or ** (32/64)

I can confirm it has been fixed, the context menu doesn't hang and its menu items work as expected. This topic may be moved to Fixed bugs subforum now.