So part of a framework of a new node is an auto refresh with GH_ScheduleeDelegae(). However Im at a loss for how this needs to operate after a week of trial and error. Having soured the forums, the bits and pieces just wont work and am not sure what going wrong with this.
Ive looked through this post and many others but zero luck on getting this to work.
I think the root of the problem is I think i should be referencing the component(which im at a loss on how to do) as well as referencing the current document ie:theCurrentDoc.GH_ScheduleDelegate() etc.
You’ll create an infinite loop and quite rapidly crash grasshopper if you’re not careful. If GH_Document.NewSolution is called, doesn’t that update everything in the document, including the component? You might be able to update a separate GH document from a controller / scheduler, if you can get a reference to it.
Or there’s a plug-in that lets grasshopper components create closed loops.
I would rethink the whole approach to be honest. What’s the higher level aim?
Wow… thank you so much… Please help me to understand a few parts about how this is working if I have it right. The ‘ghenv.Component’ is the active component and the ‘ghenv.Componenet.OnPingDocument()’ is the active document. The logic is this sets the component with the callBack to be expired and once that happens, Grasshopper refreshes that (or the other expired) components?
Another question is with how you are handling the count. If this is essentially ‘re running’ the python script n times, how is the count number carried over to the next run? I would think it would just always produce 1 because there is no loop within the script? Is that why you have an empty variable ‘e’ in the callBack function? My plan was to use time.time() to do this to keep an active count, but this way would be ALOT more straight forward!
Thank you for the feedback. The higher aim is to implement this into a slew of other RhinoInside custom scripts to be refreshing and grabbing/changing new things for CD automation.
One issue in particular is keeping a current doc.ActiveView.Id and requires recomputing the canvas and re running nodes, which when switching views, can really jam up when someone is flipping switches. This among others really needs to have an imbedded refresh option to keep up with the users movement!
Ah, wow. Thank you for the additional information. It makes sense as you normally dont check that it has been made so every time it runs its get reinstated back to the stated value. The de “foo” is a nice trick to know as well!