Yep, essentially the same problem, good catch. I redid the function that 
defines the enum list to build it from existing hidden knobs instead of the way 
it was done before, but I really need to have it use what is saved (after the 
initial node build). If there are errors, at least they would be de-buggable 
and likely due to the sources, not the gizmo. Seems obvious now, but it seemed 
more efficient to dynamically generate stuff when I first wrote the thing...

jrab


On Jun 9, 2011, at 1:25 PM, Lucien Fostier wrote:

> Great John
> 
> Thats good to know
> 
> That was what i was thinking when i mislead you about difference between 
> gizmo and group saving because of an old thread about enum knob populated by 
> DB where you end up with index when DB unmatched.
> 
> Thats the same problem i guess!
> 
> Anyway thanks for digging this new case where you need to be careful about 
> dynamic creation of enum knob.
> 
> By the way, did you find a workaround?
> 
> Regards 
> 
> Lucien
> 
> Envoyé de mon iPhone_______________________________________________
> 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

Reply via email to