GHPython Component refresh

[alexwickes]

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.

if _start:
    _updateTime = 100
    sTime = time.time()
    callback = gh.Kernel.GH_Document.NewSolution(thisDoc?,sMode?)
    gh.Kernel.GH_Document.GH_ScheduleDelegate(_updateTime, callback?)
    Debug.append(int(stime))

[AndersDeleuran]

If you need to recompute/refresh from within a GHPython component, you can use this method:

GHPython-counter from 0 to a value

You can also script the timer/trigger if you want, here’s a quick example: [2021-03-30 09_59_05-Grasshopper - 200330_GHPython_CountTo_00_] 200330_GHPython_CountTo_00.gh (3.6 KB)

If you need to do it from another component, use this method (but only target a specific component e.g. by name or guid):

Recompute Button

I was just in need of this myself (for a one-click Recompute Solution from the RCP) and ended up here. I’m not sure if this GHPython approach (based on David’s advice above) would be considered super correct, but it does appear to do the trick: def ghSolutionRecompute(): """ Recomputes the Grasshopper solution (ala pressing F5) """ def expireAllComponentsButThis(e): for obj in ghenv.Component.OnPingDocument().Objects: if not obj.InstanceGuid == ghenv.Compon…

[James_Parrott]

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?

[alexwickes]

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 again! I owe you a 22oz ribeye

[alexwickes]

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!

[James_Parrott]

Wow! That sounds amazing.

[AndersDeleuran]

@alexwickes

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?

That’s exactly right.

@alexwickes

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’m using one of several methods for creating persistent variables (i.e. that do not “reset” from iteration to iteration) in GHPython. See the links in this post for context:

Epidemic Simulation Problem

Generally speaking, when modelling dynamic systems you need at least: A) Some persistent variable mechanism (i.e. to manage the state of your system/agents) B) Some update mechanism (i.e. to step the system into the next iteration) In GHPython, problem A can be solved using at least two methods: Notably the component local if "foo" not in globals() method, and the Rhino global sticky method. Both are covered in this old thread, and I’d recommend using the former, unless you need to read the …

Edit: Just in case you miss it in the sea of links there, have a look at this old thread:

Variables deleted from script still exist in globals()

[alexwickes]

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!