Hi,
Great forum.
I’m wondering if setDependentsDirty() has an ‘issue’ playing with the normal MNodeMessage reporting system? See pseudo code below.
If one replaces the attributeAffects() dirty propagation relationship with ‘by hand’ propagation in setDependetsDirty(), and a DAG-something something is pulling on that output then it behaves just as one would expect… however, if that output is not being pulled on by DAG (or getAttr, etc), and is only being displayed in a GUI, say with an AETemplate editorTemplate -addControl / attrControlGrp ( et al)… then the value is not ‘pulled’ by that GUI control, as it normally is if a standard attributeAffects() relationship is defined.
Presumably those GUI attribute binding controls use MNodeMessage callbacks watching for changes to their bound attributes. Which, i see, are not emitting messages if the watched attributes are dirtied via setDependentsDirty()… again, if its attributeAffects() then the messages are triggered (and hence GUI controls that use that mechanism?). I’m just assuming these GUIs use this flavour of messaging?
If i didnt care about the GUI reporting state correctly, then, it wouldnt matter as it all appears to behaving as expected. But, often we do need the GUI to reflect state (as in the Attribute Editor, etc).
As in:
attributeAffects(in_attr, out_attr) # happy/triggered/updated MNodeMessages, attControlGrps
… but if you remove the above, and simply do it here instead:
setDependentsDirty()
if plugBeingDirtied == in_MPlug
affectedPlugs.append(out_MPlug)
… then no happy/triggered/updated MNodeMessages, attControlGrps, however, any other downstream thing connected to .out will behave just the same as if it were attributeAffects() established.
What can we do about this?
(i have good reasoning for why i want to do some setDependentsDirty props by hand, thats not under question).
Thanks!