Hi Steve, It looks like you’re right about the order in which things are happening. The thought of this being the case had crossed my mind, but it seemed like too strange an order to be plausible. Having the hash computed prior to knob_changed being called seems like a bit of an oversight to me given the latter’s perceived purpose (and the kinds of changes you can make from within it).
I guess I’ll have to try manually managing hash updates in append to see if I can work around this for now, but am I the only one who sees this order of operations as being slightly counterintuitive? I’m guessing there may be other reasons for calling append before knob_changed, but I can’t guess at what they are. Thanks, -Nathan From: Steve Booth Sent: Thursday, June 28, 2012 1:01 PM To: 'Nuke plug-in development discussion' Subject: RE: [Nuke-dev] Mltiline_String_knob and Knob::NO_RERENDER laziness Hey Nathan! Remember, rendering is done by the viewer, not your node, and whether or not a render occurs is determined by the Hash of the your Iop. What I suspect is happening is that the hash is being computed prior to the call of ‘knob_changed. That means that your disabling of the knob (and it’s removal from the Hash calculation) won’t be reflected in the Hash until the next one is completed, and hence the behavior you are seeing. I would recommend computing your own hash for your node by overriding the ‘append’ method, and then manually creating your own Hash that does or does not contain the value of the knob you wish to control. Hope that helps! Steve Booth From: [email protected] [mailto:[email protected]] On Behalf Of Nathan Rusch Sent: Thursday, June 28, 2012 12:40 PM To: Nuke-Dev Subject: [Nuke-dev] Mltiline_String_knob and Knob::NO_RERENDER laziness Hey everyone, I have a Multiline_String_knob whose contents are a script. Since this knob type forces a re-render every time anything in it changes (as opposed to only on Enter or focus change, like the standard String_knob), I also have a Bool_knob that I want to use to control whether changes to the knob’s contents automatically force a re-render. What I’m currently doing is the following: int knob_changed(Knob* k) { if (k->is("auto_evaluate")) { if (_autoEval) knob("expression")->clear_flag(Knob::NO_RERENDER); else knob("expression")->set_flag(Knob::NO_RERENDER); return 1; } // ... } This is behaving somewhat strangely, and I feel like it’s due to an oversight on my part. After this is called, the first character change in the text field still triggers a re-render, but subsequent changes do not (as if the flag mask state is one evaluation step ahead of the normal render process). This same behavior occurs if I test the controlling knob’s value using k->get_value() instead of just testing its storage variable. So am I right that I’m overlooking something? Or is this a known issue? Thanks, -Nathan -------------------------------------------------------------------------------- _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
_______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
