GH ScriptComponents: Input param name gets stuck - how to clean?

Name-struck? Every now and then I encounter a problem (Rhino5) with former input parameter names in script components getting stuck when the name is changed.

This causes compile errors for C# and VB.Net script components, and sometimes a “former name” of a parameter can’t even be cleaned, and so the component remains in a kind of a “deadlock” state, it simply won’t compile. The “former name” seems cached somehow, but cleaning the code cache doesn’t always help.

So, is there a proven way to fix a component when the former name goes sticky? (although sometimes the “deadlock” let go if attempting to rename multiple times, but not always).

// Rolf

I haven’t noticed that before, I guess you don’t have a reliable way to replicate the problem? If it happens again, can you try copy-pasting the script component to see if that makes it go unstuck?

No, unfortunately not anything consistent. But I’ve noticed that it seems to happen more often if the the port number and name was also defined in code, and the name is changed in code before you change the name on the capsule.

Anyway, I defined the names, both on the capsule and in code, and then changed the name on the capsule only, from FormerName to FormerName2, but no error was reported (code quietly overrides the casule settings). I had not noticed that one before. Anyway:

Fig.1. Initial component:

.
Fig 2. The name was changed on the capsule, but the component keeps using the old name (code overrides capsule settings) :

.
Fig 3. On commenting out the hardcoded name and pressing the “Run script” button, only then the name conflict is discovered ;

Notice how the signature and the code body was not in sync in Fig.2, but still the compiler didn’t discover that. To fix this particular problem, the component needs to be marked as “dirty” when modifying the capsule, and it would then know to recompile itself nest time the code editor is openend.

That’s all I have for now, but I’ll try to catch the circumstances for deadlock next time it happens.

// Rolf

Edit: Perhaps Components could be modified so that coded property names and data would update the info shown on the capsule when closning the code editor (and when pressing the “Run Script” button, then attempts to cause async would be resolved before it can happen.

So this problem occurs when you change the name of the input from within the script? I’m not particularly surprised that wouldn’t work too well, after all the name of the input is part of the RunScript signature, and therefore changes to the input should invalidate whatever script is currently running and compile again. However since the change to the name happens during an unexpected moment (i.e. during a solution, which is when you’re not supposed to make changes to the network), it may either go unnoticed, or cause some other unwanted side-effect.

The code was never designed to “change” itself while running, so I’ll have to dig deep through the logic to see what sort of problems that might cause. Thanks for the detailed report.

Not exactly. This happened when I changed the name, not in the code, but on the “outside” (on the “capsule”). See Fig.2 with text.

So I changed the name on the capsule (but not in the code) and then pressed “Run Script” (Fig.2.) and this “outside change” went unnoticed by the compiler, despite the fact that the signature actually had changed! (again, see signature in Fig.2)

So this was a surprise to me. But I only concluded that “the code has precedence over the capsule-entered name”, and hence my recommendation to recompile also on modifications of port names from the “outside”.

The deadlock problem in my original question (with perpetual compile error), is more difficult to reproduce though, but I will pay extra attention to that from now on and report any new findings.

// Rolf

1 Like

Thanks for the clarification. Still digging.