Thanks for the alternate approach Johnathan. What I ended up trying first is ignoring the knobs altogether and dealing only with their values. I’m now setting NO_RERENDER on both my bool and text knobs at creation, and then testing the state of my storage bool in append (since it seems like it must always be up to date by that point). Then, if it’s true, I just append my expression storage variable to the hash.
So far this is giving me what I want, but if it doesn’t, or if there are some edge cases you can think of where this approach wouldn’t be reliable/safe, I’ve got no problem switching it up. -Nathan From: Jonathan Egstad Sent: Thursday, June 28, 2012 2:39 PM To: Nuke plug-in development discussion Subject: Re: [Nuke-dev] Mltiline_String_knob and Knob::NO_RERENDER laziness 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: [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 -------------------------------------------------------------------------------- _______________________________________________ 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
