Try out 6.2v3. One of these bugs sounds like this one which was fixed: BUGID 15967-An erroneous expression link was created if you renamed a node whose name was in use within a group or a gizmo.
-deke On Sun, Apr 3, 2011 at 09:43, John RA Benson <[email protected]> wrote: > 6.2v1 linux and osx > also turns out it's not the updateUI callback. Arg. > > Also dealing with a nasty bug where a gizmo that's getting internal stuff > built will break connections when it's copied. Any hints on that one > appreciated. I'm hoping I can do something where I don't use the onCreate > callback but call the function that builds the gizmo after a paste: > > s = nuke.selectedNodes(filter='myGizmo') > for n in s: > buildMyGizmo(node=n) > > I see something called nukescripts.drop.dropData and in the docs: > # This function is called whenever data is dropped onto the DAG. > Override it to perform other actions. > # If you handle the drop, return True, otherwise return None. > > But I'm nut sure exactly if this applies to what I want to do or how to do it. > > any help appreciated - thanks! > jrab > > > On Apr 3, 2011, at 5:56 PM, Deke Kincaid wrote: > >> What version of nuke? This sounds like a bug about erroneous expressions >> linking from inside gizmos to external nodes. It was fixed a few v releases >> ago. >> >> -deke >> >> On Apr 3, 2011, at 7:52, John RA Benson <[email protected]> >> wrote: >> >>> Hey there - >>> >>> I have a gizmo that is doing a funny thing. Sometimes when I create it, a >>> green expression link will appear to another gizmo of the same class. If I >>> click on the gizmo it's pointing to, the expression goes away. Yeah, I'm >>> doing some funny stuff with updateUI, but it's nothing (although I could be >>> totally wrong) that would create that link. >>> >>> I can do this: >>> s = nuke.selectedNode() >>> d = s.dependencies(nuke.EXPRESSIONS)[0] >>> d.dependent(nuke.EXPRESSIONS) >>> >>> and I get 's' showing me that it has an expression pointing to 'd', and >>> d.dependent() points back to 's'. Ok, good. >>> >>> if I deselect s and then select d (the green arrow then goes away) and do >>> d.dependent() again, I get an empty list. >>> >>> None of the knobs on s or d have an expression, so maybe it's from >>> something inside the gizmo that I'm pythonically setting? >>> >>> What would be swell is to find out where this mystery expression is coming >>> from in the first place. is there a >>> 'tellMeWhichKnobHasTheExpressionSinceNuke.EXPRESSIONS_tellsMeThereIsOne' >>> function? >>> >>> hmmn - it appears to be due to the updateUI callback, but it would really >>> be good to know which expression is being mysteriously generated by it. >>> >>> Cheers! >>> JRAB_______________________________________________ >>> Nuke-python mailing list >>> [email protected] >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> _______________________________________________ >> Nuke-python mailing list >> [email protected] >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > _______________________________________________ > Nuke-python mailing list > [email protected] > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > _______________________________________________ Nuke-python mailing list [email protected] http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
