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
