@Japhy sorry to poke you again, any news on this matter?
@eirannejad is the most knowledgeable in this regard.
Hi @eirannejad, poking you since you were mentioned a few days ago. Could you check these issues and give some feedback?
@Japhy @eirannejad just poking to this issue again.
Honestly, this is one of the most important features in Rhino - the ability to compile grasshopper scripts into plugins. I would love to set up a meeting with the development team to show what it is we are actually doing - I know that @kiteboardshaper would love to join.
What you have created here is amazing - and I sometimes get the feeling that you are not aware of how insanely useful it is, and how we are using it.
Iâm now distributing plugins to clients who keep buying more Rhino licenses, because this is possible. But itâs a little frustrating to have to rely on the Human Plugin now that we have the Rhino Tab - so please! have a look at this as soon as you can.
2 Likes
Looking into this and will update. Sorry for the late reply.
1 Like
Awesome Ehsan!
Thanks!!
SoooooâŚ.. any updates?
@eirannejad Sorry to ping again, but itâs been 2 weeks without any sign of updates on this matter. As @Timo_Harboe_Nielsen said, this is one of the most important features in Rhino. Please do not leave us hanging.
1 Like
@ale2x72 Sorry for the delays man. Will update here soon. Got distracted putting out other fires.
@ale2x72 Looking at this thread today but kinda feel like I am being an archeologist trying to make sense of the many points and statements being raise on this thread around UI and Grasshopper execution model. I see @Japhy as asked for a simple example that replicates the problem but I donât see any posted yet.
Would you mind telling me what is the last problem that this conversation thread is waiting on? Are there any GH or RHP files that replicate the problem and doesnât require me installing various plugins just to get the example working?
I am watching this thread and focused on fixing whatever this problem is so any info is appreciated.
@eirannejad long story short: there has been a change in the GrasshopperPlayer behavior in compiled plugins between SR15 and the latest that broke several plugins (including mine), which I describe in my original post. @kiteboardshaper proposed a workaround that I marked as a solution, but it does not solve the problem, which is somewhere in the changes that occurred in Rhino after SR15.
Here is where I pinpoint the issue: Grasshopper Player in compiled plugin issue - #13 by ale2x72
As I said to Japhy in that same reply, the issue is related to the persistence of the Player when using a custom UI form, independent of the plugin used to build the UI (Synapse, DKUI, othersâŚ). Besides, the issue did not depend on any of the specific plugins since, in the SRs prior to 15, the same configuration worked as expected.
From the workaround suggested by Kiteboardshaper, something else came up: plugins compiled with the Script Editor and the Script Compiler behave differently. See my tests described here.
I hope this quick recap helps.
EDIT: I unmarked the solution, maybe it was giving the wrong impression that the issue had been solved somehowâŚ.
1 Like
@ale2x72 This is incredibly helpful! A few follow up questions:
A) GH Player
I downloaded Test_RCP_SC+SE source.zip and loaded up the Test_RCP_Synapse_SE.gh file in Grasshopper. Seems like context print component only gets results when exit is clicked on the dialog. Here is what I see:
- Run GrasshopperPlayer command
- Select
Test_RCP_Synapse_SE.gh - Dialog shows up with Bake and Exit
- Click Exit
- Rhino prompt asks for typing âxâ to exit
- Then Context output shows up with message
End Program
What is the correct expected behaviour?
B) Script Editor
When running a gh definition that is published and embedded in an .RHP by the script editor, it is basically being handed to the GrasshopperPlayer API to run the definition. There are two extra things that script-editor-published-gh-definition does:
- Iterate over all context input components and clear their caches. This forces the input components to ask for input every time you run the command
- If
Keep Openis not checked in the grasshopper definition settings, it will clear drop the cached definition when the command ends to it does not keep it in memory when not needed.
Hi @eirannejad, see my original post. The Test RCP plugin linked there contains the expected behaviour, and used to work up to SR15; then, it stopped working when I tested back (unchanged) in SR21 and later releases https://discourse.mcneel.com/uploads/short-url/udt9stilO9d7j5S6uH9u76Zt8W2.rhp . From the same post, this is the issue, that affects only the compiled version (not the definition when run directly from the player):
The .gh definitions have the Keep open option checked.
Any other file/script/plugin posted in this thread are attempts to solve/circumvent the problem.
Regarding what you describe in your point B, was it already like this before SR15? Because the same plugin I posted at the beginning used to work, and the code hasnât changed.
1 Like
I think itâs important to step back and recognize that this entire thread â along with several similar discussions on the forum â is really just a symptom of a deeper, unresolved issue.
Most of us would probably agree that none of these problems would even exist if there were a supported, reliable way to programmatically close or terminate a Grasshopper (GH) definition â particularly when:
-
Itâs run through the Grasshopper Player, or
-
Itâs compiled via the Script Editor or Script Compiler.
Right now, users have to resort to workarounds and hacks, which are often unreliable or break across versions. Thatâs why I believe the real solution is to provide an official component or API call that allows a script to gracefully shut itself down once itâs done.
@eirannejad Ive written up a spec for the required GH component as I see it here:
If you build this/solve this larger issue all will be right in the world!
Cheers
DK
2 Likes
@kiteboardshaper I read the post. Makes sense. From what I gathered this is an issue when GH definition is opening non-modal windows that need to recompute the definition when parameter changes and close and dispose the definition when window is closed. If I am correct, I think the GH UI component framework is the best place to put such a component in. Correct me if I am wrong please.
@ale2x72 I am still confused. If someone can write down what the actual problem is and what the expected steps are it would help tremendously. Here is the GH definition I downloaded from the files here. The gh definition seems to be working both in GH and from published command. I donât know what am I missing.
TestSynRCP.zip (575.5 KB)
@eirannejad if you can bare with me for a couple of days. As my handle suggests kiteboarding is business/life and Iâm team captain for the South African team in the worldâs biggest kiteboarding competition - going on right now. We are currently chasing wind and waves all around the southern tip of Africa.
As soon as this current wind cycle finishes (in a few days) Iâll be able to get back to my desk and give you some examples to work with.
I know @Timo_Harboe_Nielsen has been trying to arrange a meeting with you which I would gladly be a part of, that would likely help this process a lot.
Cheers
DK
1 Like
Sure thing. Have fun there. I will do my best to get to the bottom of this and understand where the problem in the meantime
@eirannejad it works because you used the one with the workaround suggested by Kiteboardshaper (using a Get Boolean component - in your video you can see the âType x to exitâ prompt in the Command line when you run the compiled version):
Try recompiling it like the original version (no Get Boolean); this is what used to work and doesnât work anymore:
Test_RCP_Synapse_SE_noGet.gh (81.7 KB)
Would you agree that that you use THIS piece of code in your GH because there is NOT a supported âContext Close GHâ (or similar) component:
Thanks
DK