Hello @HerrMay,
Thank you for the updated information. I had a look at your problem, and I could reproduce it, but it is primarily a problem of your code as suspected.
I document below how I analyzed this problem not as a passive aggressive expression of "look how easy that is!". But to give an insight on how to approach such debugging task. The core rule is here to question one's own assumptions and assure that things are indeed how we think they are.
Debugging
So, when one follows your steps, one indeed ends up with something like this:
[image: 1694702115621-8fdef1aa-1a5e-43d8-8cdb-42b480fd4f0d-image.png]
Your assumption here was that the icon handling is bugged on our side. For that to be true, the tag on Null.2 would have to be IDC_ACTIVE_ON but with the icon handling failing and Cinemas 4D rendering it as disabled.
So, I checked the value with this code:
# Set custom icon for node.
if id == c4d.MSG_GETCUSTOMICON:
host: c4d.BaseObject = tag.GetObject()
isFirst: bool = host.GetUp() == None and host.GetPred() == None
if isFirst:
print(f"TOP: {host.GetName() = }, {tag[IDC_ACTIVE] = }")
else:
print(f"OTHER: {host.GetName() = }, {tag[IDC_ACTIVE] = }")
icon = self.PLUGIN_ICON_INACTIVE if tag[IDC_ACTIVE] == IDC_ACTIVE_OFF else self.PLUGIN_ICON_ACTIVE
data["bmp"] = icon
data["w"] = icon.GetBw()
data["h"] = icon.GetBh()
data["filled"] = True
Which will print this when you add the tags:
[image: 1694702486106-baebed6a-fdc0-4d53-8214-1d6b2011cad8-image.png]
So, the topmost tag is indeed inactive and the icon rendering is correct. The question is now: 'Why is that tag inactive because we initialize all tags as node[IDC_ACTIVE] = IDC_ACTIVE_ON ?' The likely culprit is just a few lines above, as we toggle there the active state of our tag.
# Handle double click on tag.
if id == c4d.MSG_EDIT:
if tag[IDC_ACTIVE] == IDC_ACTIVE_OFF:
tag[IDC_ACTIVE] = IDC_ACTIVE_ON
else:
tag[IDC_ACTIVE] = IDC_ACTIVE_OFF
And indeed, when we comment out these lines, we end up with this when creating multiple new tags.
[image: 1694702820259-ebddd8e2-ff78-47f3-a4ca-40cbd26ac047-image.png]
Moreover, when we revert our change of commenting out that code and test our assumption 'only happens for multi-object selections', we can see that this does not hold true:
[image: 1694703033146-e5f2a8dd-2ebd-4555-8188-d769b84895e3-image.png]
We can now check our own comment:
# Handle double click on tag.
if id == c4d.MSG_EDIT:
...
and check MSG_EDIT:
[image: 1694703119443-de39ee11-81d9-4e68-a2a6-a4c4dd182b84-image.png]
The documentation says, "for example". So, the event does not capture a double click, but double clicking a BaseObject to edit its name is one example of an edit event. Adding a tag to an object apparently also emits MSG_EDIT to the tag, and when you have a multi-selection, MSG_EDIT is only emitted to the first element in the selection.
Conclusion
That behavior of MSG_EDIT in regard to tags and multi-selections is of course quite odd, but I would not consider it to be a bug, as an edit event is not really defined for tags in the first place. And while I understand what you want to do here, I would also say that what you do in MSG_EDIT is a violation of the UX principles of Cinema 4D. Double clicking a tag should not edit a random parameter in it. We strive for Cinema 4D having a seamless UX-experience for users including plugins. So, we rather not support it when plugin authors are trying to break these UX rules.
But I will nevertheless talk with my colleagues about the subject and if we want to consider this behavior of MSG_EDIT to be a bug.
Cheers,
Ferdinand
