No worries, the first example was probably misleading, and I really only thought of a case where you would update a single knob.
Glad it worked, though. ;-) Cheers, Ivan On Thu, Jan 19, 2012 at 1:28 PM, John Vanderbeck < [email protected]> wrote: > Ahh I got you. Yeah that makes sense now. I misunderstood you to mean > each individual knob needed to be forced to update, but what you mean is > that just forcing one knob to update causes Nuke to refresh the whole panel. > **** > > ** ** > > Works perfectly now thanks!**** > > ** ** > > John Vanderbeck**** > > Technical Artist**** > > Digital Domain Media Group**** > > ** ** > > NOTICE: This communication may contain privileged or other confidential > information. If you have received it in error, please advise the sender by > reply email and immediately delete the message and any attachments without > copying or disclosing the contents. Thank you. **** > > ** ** > > ** ** > > ** ** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Ivan Busquets > *Sent:* Thursday, January 19, 2012 3:52 PM > > *To:* Nuke Python discussion > *Subject:* Re: [Nuke-python] knob.setLabel() doesn't update > untilpropertiespanel is re-opened**** > > ** ** > > Well, if you have that many knobs, then yes, forcing a knobChanged for > each will be slow. > But the idea is to just force one of them, so the UI knows that something > has changed and updates properly. > > For example: > > for k in [knob_list]:**** > > k.setLabel('new_label')**** > > ** ** > > # And then use the last item in that list to force-update**** > > k.setFlag(nuke.KNOB_CHANGED_RECURSIVE)**** > > k.clearFlag(nuke.KNOB_CHANGED_RECURSIVE)**** > > ** ** > > Does that make sense? > > Cheers, > Ivan**** > > On Thu, Jan 19, 2012 at 12:32 PM, John Vanderbeck < > [email protected]> wrote:**** > > Hey Ivan,**** > > **** > > I agree about .changed(). In fact that was the first thing I tried, as > you have to do that with Roto_Knobs, but alas other knobs don’t appear to > have that function.**** > > **** > > On the bright side your workaround works, but is incredibly slow. It > takes just as long, if not longer, than deleting the knobs and rebuilding > them which is what I was trying to avoid. I have a long list of knobs that > takes about a minute or two for Nuke to initially create. By reusing that > list and simply renaming them all to the new state, the update is instant > with the exception of the update bug. With your workaround, the update > does occur properly, but is way to slow – just as slow as completely > rebuilding the list of knobs :(**** > > **** > > **** > > John Vanderbeck**** > > Technical Artist**** > > Digital Domain Media Group**** > > **** > > NOTICE: This communication may contain privileged or other confidential > information. If you have received it in error, please advise the sender by > reply email and immediately delete the message and any attachments without > copying or disclosing the contents. Thank you. **** > > **** > > **** > > **** > > **** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Ivan Busquets > *Sent:* Thursday, January 19, 2012 3:01 PM > *To:* Nuke Python discussion > *Subject:* Re: [Nuke-python] knob.setLabel() doesn't update until > propertiespanel is re-opened**** > > **** > > Hi John, > > IMO, this is yet another case that reveals the need to have a > <knob>.changed() method to force-trigger callbacks associated with changing > a knob. > > In this case, though, you can force the required changes by setting and > unsetting the KNOB_CHANGED_RECURSIVE flag. > > > k = <your_knob_object> **** > > k.setFlag(nuke.KNOB_CHANGED_RECURSIVE)**** > > k.setLabel('newLabel')**** > > k.clearFlag(nuke.KNOB_CHANGED_RECURSIVE) > > **** > > On Thu, Jan 19, 2012 at 11:52 AM, John Vanderbeck < > [email protected]> wrote:**** > > I just wanted to check if anyone else is seeing this behavior, and > possibly is aware of a workaround?**** > > If I call setLabel() on a knob, in my case specifically a series of > Boolean_Knobs, the actual label does not change until the user closes the > properties panel for that node, and reopens it. Once reopened, the correct > labels are shown.**** > > I thought I might work around it by scripting the panel to close then open > using node.hidecontrolPanel() and node.showControlPanel(), but then I ran > into another issue where the back to back calls don’t work. The panel will > close, but not open when the function is called.**** > > John Vanderbeck**** > > Technical Artist**** > > Digital Domain Media Group**** > > NOTICE: This communication may contain privileged or other confidential > information. If you have received it in error, please advise the sender by > reply email and immediately delete the message and any attachments without > copying or disclosing the contents. Thank you. **** > > > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python**** > > **** > > > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python**** > > ** ** > > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > >
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
