GH - No screen update while in for-loop

When I automate a slider in Gh I expect the following code to update the screen while I’m watching it. But instead the screen is “locked” while in the loop.

What can I do to allow screenupdate during the loop?

gh = Rhino.RhinoApp.GetPlugInObject("Grasshopper")
rs.EnableRedraw(True)
for abd in range(0, 5, 1):
    gh.SetSliderValue(slider_y_abd, abd)
    time.sleep(0.5)

// Rolf

Use RhinoApp.Wait() for this
http://developer.rhino3d.com/api/RhinoCommonWin/html/M_Rhino_RhinoApp_Wait.htm

I tried Wait but still no screen update in the for-loop, only after it’s done. And when the for-loop is done mouse clicks and dragging no longer works on the Gh Canvas. Unresponsive.

_Buggy_Py_Sliders.gh (16.0 KB)

// Rolf

Since it is quite likely that someone would want to set multiple sliders all in one go, there is no automatic new solution. you must run a new solution after you’re done changing sliders. This should automatically result in screen updates, no waiting required.

What does “new solution” mean, and how do I invoke one in the following code? (I get no hits on “Solution” in RhinoCommon

gh = Rhino.RhinoApp.GetPlugInObject("Grasshopper")
rs.EnableRedraw(True)
for abd in range(0, 90, 1):
    gh.SetSliderValue(slider_y_abd, abd)
    Rhino.RhinoApp.Wait()

I keep getting the following error message(s) multiple repeatedly. The screenloocking seems to have gone away though, when I skipped writing to the outport (a") without a being connected. (a bug?).

// Rolf

I would advise against using methods such as time.sleep for these types of problems (assuming I understood it properly). I typically use either the vanilla Grasshopper Timer component (see attached file) or write an IronPython function that does the same thing (see this example). Also, remember to expire the slider after setting its value. Hope that might help inspire a solution.

160406_RotateSlider_00.gh (2.8 KB)

Than you for your hints!

Regrding the the sleep() command it was only due to prototyping and I wanted to have a chance to see if the sliders stepped up properly… :slight_smile:

What I plan to do is to bake some geometry at each step of the Slider + capture for video animation etc, which seems risky to do with a timer (like, how do I know it’s done baking before next tick?).

I would also use the stepped values from the for loops for stepwise update of parametric creation of geometry to be baked, and these parametric values would in turn be affected by at least two other sliders/for-loops combined. I will nest at least three for-loops (with sliders) to update the geometry and bake it at each step.

I based my proto-code on the following video (Scripted from RhinoPython, not from GhPython) where the stepping of sliders didn’t need timers. Wouldn’t a timer only be at risk of being out of sync with the baking(?) :

Automating Grasshopper Part 2 | Designalyze (and 3)

I also use instance guids to identify the sliders :

gh = Rhino.RhinoApp.GetPlugInObject("Grasshopper")
slider_y_abd = "9ec5e15c-b939-4643-b90c-7aaf84a38813"
for abd in range(0,  10, 1):
    gh.SetSliderValue(slider_y_abd, abd)

// Rolf

You’ll need RunSolver(false)

See this page for a list of all available methods on the Grasshopper scripting object.

Do note that you have more direct ways of accessing Grasshopper from a python script within Grasshopper. That object you’re using to set sliders was specifically designed to be used from within a VBScript.

Thanks! :+1:

// Rolf

In that case I would suggest scripting the update (enabling you to check things before updating, activate with a boolean toggle etc). Attached a minimal working example of this:

170531_GHPython_Timer_00.gh (3.2 KB)

Edit: Just tried “baking” something downstream from the counter/update component, this appears to work as expected, but I suspect this could cause concurrency issues depending on the specific case:

170531_GHPython_Timer_01.gh (4.0 KB)

This looks really good. I will later try to bake my geometry as well. Many thanks!

// Rolf

1 Like