Uncorrect [ContentPlugins] section in wincmd.ini

[thisIsAUser]

The section [ContentPlugins] in wincmd.ini is inconsistently/uncorrectly filled by the two dialogs "Content plugins" and "Change attributes" - this is sometimes preventing the listing of the plugin WDXTagLib as expected under "More attributes" in the "Change attributes" dialog.

The bug could be reproduced by these steps (I used 32bit TC8.51a on Win7 64bit):

1) After installing TC and adding the plugin WDXTagLib via the "Content plugins" configuration dialog, the section [ContentPlugins] contains only the path to the plugin (entry "0=...").

2) Then, after calling the "Change attributes" and (without success) searching under "More attributes" for the installed plugin WDXTagLib and closing the "Change attributes" dialog and closing TC, the section [ContentPlugins] contains also the entries "0_detect=...", "0_date=..." and "0_flags=0".

3) Only after manually correcting the entry "0_flags=0" to "0_flags=1", the plugin WDXTagLib is correctly listed under "More attributes" in the "Change attributes" dialog.

Please note that the configuration via "Custom Columns" dialog works with the plugin WDXTagLib after step 1) already and that this dialog correctly writes "0_flags=1" to section [ContentPlugins] at this stage and the WDXTagLib is then listed under "More attributes" in the "Change attributes".
But, if the configuration "Custom Columns" dialog is the first time called after step 2), the entry "0_flags=0" is not overwritten and the WDXTagLib is not listed under "More attributes" in the "Change attributes".

This bug report covers (partly) the problems reported under the topic "WDXTagLib - content plugin for audio files":
http://www.ghisler.ch/board/viewtopic.php?t=18518&start=30&postdays=0&postorder=asc&highlight=

[MVV]

Well, 0_flags=1 contains only flag contflags_edit meaning that plugin supports editing of fields (i.e. may be used in change attributes dialog). This parameter is used by TC to cache plugin's answer on first ContentGetSupportedFieldFlags function call.

I think it is a plugin problem. It should always return a combination of all fields' flags when function is called with field index -1, but it seems that it returns 0 when it is called for the first time from attributes dialog.

It's first called with FieldIndex=-1 to find out whether the plugin supports any special flags at all, and then for each field separately.

I've tested it with my NTLinks plugin, and it works correctly: when there is no 0_flags value, TC calls ContentGetSupportedFieldFlags with field index -1 and stores exactly the same value that plugin returns.

[thisIsAUser]

To summarize my and your post:

TC seems not to receive the combination of all fields' flags if the WDXTagLib plugin is called the first time (after its installation) via the "Change attributes" dialog.

But if the WDXTagLib plugin is called the first time (after its installation) via the "Custom Columns" dialog, TC seems to correctly receive the combination of all fields' flags.

My conclusion would be that the ContentGetSupportedFieldFlags function is properly implemented in the WDXTagLib plugin, but the function is not called by TC with field index -1, if the plugin is called the first time (after its installation) via the "Change attributes" dialog.
So I guess it is a TC problem...

[MVV]

It is not a TC problem. TC calls ContentGetSupportedFieldFlags correctly from Change Attributes dialog, and I've tested it with my plugin (plugin is loaded and function is called just when you press 'More attributes' button because TC needs to know which plugins should be displayed in list). You can test it yourself with any plugin that supports fields editing, e.g. with my NTLinks.

It is a WDXTagLib plugin problem that it returns 0 instead of correct combination of all fields' flags.

[poiuytr]

Can confirm it is a plugin bug. Fix is on its way.