Trigger Tag



  • Hi,

    I have a TagData plugin which is dependent on the information available in another tag (could be Tuvw, Tphong, Tvertexmap, Tvertexcolor, ... even any of my own-created tags).
    When any of the dependent tags get removed by the user, I would like to disable the tag (or some features it provides). What would be the best way to be triggered?

    Currently I tested by implementing the TagData::GetDParameter, and check for the presence of the dependent tag. If not present I then set the enable checkbox of my tag to false.
    A better solution would be to handle this in the TagData::Message, but I haven't found a particular message which gets sent to the tag which might trigger the above checking and disabling.



  • hi,

    There's no function or message to do that.
    You could maybe create a MessageData to react to a EVMSG_CHANGE
    That MessageData retrieves all your plugins and send them a message.

    But GetDParameter is also a good option.

    Cheers,
    Manuel



  • @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.



  • hi,

    I though you were using a hidden BaseLink parameter on your tag to point to the other tag.
    That way if the user press undo the BaseLink should be updated and it should trigger GetDParameter

    Could also be a InExclude parameter if you need several tags.

    Cheers,
    Manuel



  • @m_magalhaes said in Trigger Tag:

    I though you were using a hidden BaseLink parameter on your tag to point to the other tag.

    Ah, didn't think about that. Clever.