I got a bug difficult to reproduce : a button sometimes continue sending “True” to its value listener while the user has released the mouse button.
Where can this come from ?
The button returns to a normal bevahior when i manually desable and enable it.
I have reviewed the file you sent, and reproduced the issue in question (this in itself was not easy!). I am fairly sure the problem is with either your script or with Grasshopper itself - there have been prior reports of scripting components in GH with slow/long running functions failing to return control of mouse events back to the canvas. I do not think this issue in general is something I can solve.
However, I can recommend a workaround. In my preliminary tests this approach below eliminates the problem you are experiencing - though I can’t guarantee it will always do so. Rather than using metahopper enable/disable on your script, I would recommend leaving the script enabled and using MetaHopper “Set object value” to decouple the button triggering the script from the value returning from HUI. This is easier to demonstrate than explain:
In my tests with this configuration, the button consistently returned to false and the script never double-solved.
In general, these “decoupled” scenarios using metahopper with Human UI make for more reliable and easier to maintain grasshopper definitions - it removes a wired connection from the output of the HUI into the “business logic” of the definition in favor of a “remote” or wireless connection. There are many examples of this in the “Decoupled Snippets” available on the HUI food4rhino page.
Well i met the same problem using the decoupled scenario. After some tests, the HUI button was staying on True value systematically (even after manually having disabled and enabled it), until I delete the Create Button component and create a new one. Painfull…
I’m facing the same issue even with the new update of Rhino/Grasshopper. If I have a button on the canvas instead of Human UI then the problem is fixed. But it’s not the best way. I wish we could do something about it.
The “decoupled” approach above - with a toggle rather than a button - has worked in every case I’ve ever encountered personally. Button on/off staying on
Beyond that you’ll have to do some custom scripting to trigger your simulation - such as launching it from a delayed “ScheduleSolution” call if possible.
Hi all – this is a problem I’ve run into many times, it often happens when using a button to trigger a Rhino command or other system event that opens a dialog.
Not sure if this will work with a long-running simulation but the solution I have used in the past is something I call a “Spoof Button Release” component, which essentially is a component that accepts a boolean input and when true, schedules a solution with about 100ms delay. You use this component directly after a True-Only button. Here’s a C# version of the custom component I use.