Button on/off staying on

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

that’s… not recommended. You should never expire a “create” component after the window has launched.

Hello Andrew,

Still struggling with this problem.
Any idea how to fix it ?

I’m forced to open the hood of the definition and get my hands dirty by baking the old fashioned way :frowning:

I’ve given you everything I’ve got on this one, sorry.

Hi Andrew,

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.

Frank

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.

Cheers,
Marc
SpoofButtonRelease.gh (10.7 KB)

2 Likes

always works True after clicking. how to treat it? :pleading_face:


sometimes there are no such problems…

As mentioned in another thread, I’m using a keyboard triggered button and have since not had problems with a button.

Thread regarding Elefront baking problems:

And the keyboard shortcut:

1 Like

yes i am using. Elefront Bake :upside_down_face:

So maybe try the button shortcut I mentioned. I think the only downside to Elefront bake all is that you will have to plug in the Grasshopper button to all bake components manually

I rebuilt the button nodes. it helped no problem …
I use the Elefront because it can bake and connect to a group.

1 Like

In this post maybe a step for a solution, i try the code but the problem with expire solution

button.gh (4.9 KB)

So I managed to created a minimal example of this:
MinimalExampleOfStuckButton.gh (71.1 KB)

I guess what happens is something along the lines of:
Active interface is Grasshopper
Grasshopper listens to mouse click down
The click down CHANGES the active interface to Rhino temporarily. (same with Baking)
Grasshopper can no longer listen (because it’s not active interface) and will not notice that I release the mouse button
Hence it stays True

I´m facing the same issue :frowning:

Hi has there been any progress regarding this? Just ran into the same problem while trying to have a Bake button in Human UI and using Elefront baking component (because it allows me to group and overwrite on layer). Even with decoupled method, the problem returns randomly. I think @timonielsen rightly pointed out the underlying issue. For now, my workaround is just avoid button for this case and use a toggle. Or maybe use some sort of time based trigger to overwrite button value?

Yeah, I´m also using toggles which is odd :frowning: