@m_magalhaes
Thanks for the reply.
Following is just for completeness, to help others in case they're looking for something similar.
I have used MessageData in the past, reacting to EVMSG_CHANGE and performing specific triggers via messaging. However, it is a pain to filter out the exact specific situation, as the EVMSG_CHANGE is just too broad. It would at least be helpful if the message would provide some additional information, telling us it was sent because of a delete, an insert, an update, ... And maybe even the item the change was related to. And not necessarily by specific instance, but by type would already be a huge step forward.
Now the message is just sent with every change, whatever that change is.
I have refrained from using the GetDParameter solution.
In my particular solution I disabled my tag in case another tag was not present. The dependent tag was removed as a result of being deleted by the user. However, the user removing the tag had resulted in an undo being created.
When the user would undo that action my tag would remain disabled, since I didn't create an undo. If I would have created an undo, the user might simply undo that action, and my tag would be enabled again, with the necessary dependent tag still being removed. Which then would result in my tag disabling itself ... in an undo step, which the user might undo, etc ...
In the end, the whole "disable oneself" is not the solution.
Then, how did I fix this?
Every function that requires the data from my tag first checks if the tag is enabled. I had moved the functionality of the enabled-checking into a method: Bool IsMyTagEnabled();
Now, instead of that method only checking for the tag to be enabled it also checks if the dependent tag(s) are present, if not it returns false, no matter if my tag is enabled. For clarity I had renamed the method to Bool IsMyTagEnabledAndValid();
Not the cleanest solution, but hey, you work with the tools you have at hand.
