So why does TC call ContentGetValue() in the plug-in chooser dialog despite the flag and the docs?
It doesn't do this here with my internal field tc->partner file with other extension, so it must be caused by specific parameters.
If you can send me a pre-release version of your plugin, I can check in the debugger why it happens.
To me it seems that the contflags_fieldsearch make sense only with ft_fulltext(w) as it can only return a boolean filling the BOOL pointed value reading the search term and the operator.
Have a look at my internal field tc->partner file with other extension in TC 10. It's used for searching. For example, seearch for
*.cr2 and set tc->partner file with other extension to jpg to find cr2 raw images which have a partner file with the same name but extension jpg.
To be clear, without the search mechanism the partner field should return the list of all files extension with same names. -> a ft_fulltext if you consider one extension by line.
[edited]-------------------------------------------
Your partner field works inside TC as described. The standard TC implementations "wdx_filesys" is missing from src folder and no sample folder is present on the repository.
The regular sample https://plugins.ghisler.com/content/wdx_filesys_src.zip do not reflect 2.12.
I would like to make a try but i always use your cpp sample as starting point to at least verify that once compiled it works as designed . Working from the document only is not as efficient and debugging more complicated as I do not have a reference i instrument (debug_view) to compare with.
I have made some more tests in the debugger now:
ContentGetValue() is called for the field preview in the plugin choose dialog. Of course it makes no sense for fields using ContentCompareFiles/W, so I will remove the call. In my own internal plugin, I'm returning ft_nosuchfield.
The field supporting ContentCompareFiles/W is hidden when you configure custom columns or use the multi-rename tool. I think it's best to do the same when using the text search in plugins too. Why?
1. You can't set a compare operator in that field. Because the plugin can return its own operators, it's not clear which one should be used. For example, the plugin may not use "contains" or "=", but something entirely custom.
2. The user can enter any text there, so it wouldn't work with fields like "multiple choice" where he had to pick a field from a combobox.
