Hello, 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. Thank you in advance, JL

Andrew I can send to you my definition privatly if you need it. … It’s always the same problem of lauching external treatment (word document generation with COM) and notify correctly its end on the GH/HUI user interface : [image] Toggle button send its value more than one time Human UI Hello, In another topic (*) i discovered that the Toggle sometimes send its ‘true’ value more that one time. It’s annoying since it throws some big component. My Toggle is on a tabbed view, with 3 tabs. The problem seems to never occur when i put the toggle on the first tab, but it does when it is on the third ! JL _ (*) Big VB component (involuntarily) runs in a loop [image] Big VB component (involuntarily) runs in a loop Grasshopper Developer Hello, I have a VB component with many inputs, writing a Word document through *Microsoft.Office.Interop.Word" DLL (1). Sometimes, the program runs in loop : it doesn’t stop after the Word document written, but it creates another Word document, again and again. My hypothesis : The GH definition is re-evaluated (even if i don’t see why) while the VB component execution is not over. What do you think ? [IMG_big%20VB%20component] __ (1) https://discourse.mcneel.com/t/interop-with-word-and-…

Yes, why don’t you send me a copy of your definition and I can take a look. But my response to the other topic holds; if I can’t reproduce it, it’s extremely hard to solve the problem.

and as per the replies to the second post - the simpler the definition you can send that exhibits the problem, the better.

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: [image] 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. Hope this helps.

Thanks you very much for the time you spent, Andrew. I think it will help - i imagined a solution such as this one. I’ll let you now :slight_smile: …

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…

Here is a clue : In the VB component started with the Button, I have been replacing the following line, warning the end of the Word generation to the user : Rhino.UI.Dialogs.ShowMessageBox(“It’s finished!”) by System.Windows.Forms.MessageBox.Show(“It’s finished!”). (I did that because Rhino.UI.Dialogs.ShowMessageBox() has been been removed in Rhino 6 and i want a code compatible with both Rhino 5 and Rhino 6) With the System.Windows.Forms.MessageBox.Show() call, the bug is systematic, not depending on that fact that the decoupled scenario is implemented or not. JL

Is there a way to detect the end of the slow/long running function, and then force the HUI button to False, without Grasshopper detecting a loop in the definition ? JL

Hi, I’m having the same issue and it’s very annoying. The button stay on true as well but only when I use the button to start a simulation. Is there any update? Best regards

Hello, We have found a palliative which does the job : put a “Expire solution” component (Human plug-in) activated with the values Listener of the button. JL [Palliative%20for%20Button%20on-off%20staying%20on]

Button on/off staying on

Grasshopper Human UI

JLH March 22, 2018, 3:20pm 2

Andrew I can send to you my definition privatly if you need it.

… It’s always the same problem of lauching external treatment (word document generation with COM) and notify correctly its end on the GH/HUI user interface :

Topic		Replies	Views
Human UI, True only Button: Possible Solution Human UI windows	0	364	February 2, 2024
Button stays in "True" position when using a dialogbox Grasshopper	11	1300	October 15, 2019
Listener stay True on Human UI Human UI	1	778	April 24, 2019
"button" component that freezes the Grasshopper canvas? Grasshopper	8	1486	November 10, 2025
Issues with Buttons: Freezing Canvas and Clearing Data After Execution Grasshopper windows , boolean-toggle , buttons	5	275	December 13, 2024

Button on/off staying on

Related topics