Normally knob_changed() is called after user interaction and the knobs need to be in their updated state to make decisions. There's valid reasons for it being before append() too, but it is what it is.
Instead of doing this in knob_changed() do it in knobs() instead and make sure your bool knob has the EARLY_STORE flag set, then set the state of the string knob at the end of the knobs() method, before append() gets called. -jonathan On Jun 28, 2012, at 2:14 PM, Nathan Rusch wrote: > 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: nuke-dev-boun...@support.thefoundry.co.uk > [mailto:nuke-dev-boun...@support.thefoundry.co.uk] 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 > Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > _______________________________________________ > Nuke-dev mailing list > Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
_______________________________________________ Nuke-dev mailing list Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
