Hi !
To me, it would make sense that GH definitions were recomputed as soon as a new Rhino file is opened in a given Rhino session.
In particular, some definitions create layers when they are launched, but if the Rhino file is changed, this process is not repeated and the layers are not available for bakes.
Other issues appear due to not re-initializing the definition, and for the user, it’s quite confusing, specially since they only see the interface made from Human UI .
It would be annoying though if your script didn’t rely in any way on the Rhino file but does take a long time to recompute.
There already is a mechanism that invalidates specific components when changes in Rhino occur, and it sounds like that mechanism should either be used already, or extended. At the moment Grasshopper assumes that components only care about referenced Rhino objects (not layers, or documents, or settings, or …). So if a component has registered a specific ID with itself then it will be expired whenever a new Rhino document is loaded.
It sounds like the problem you’re seeing could be fixed without changes to GH core if the components that care about documents register some bogus ID via the RegisterRemoteIDs() method. Which components are these?
Well, the particular example of layer creation is related to the Human “Create/Modify Layers”.
@andheum would it make sense to you to register a nonsense Guid so that the layer create component runs again whenever a new Rhino document is loaded?
Yes, that makes sense as a solution. @osuire - not making any promises I’ll get to this any time soon… I don’t have much bandwidth for GH development these days
Never mind, initial test show it’s not working as expected. Still digging.
Hi Andrew,
Maybe you could add a “Recompute” component in Metahopper.
Then I could add a button in my interface so that the user can recompute the definition when the Rhino file is changed.
It would be better If this was automatic, but as it is, the poor fellows get confused.
Great, now I can’t repeat it not working. The following code seems to do the trick:
using System;
using System.Collections.Generic;
using System.Drawing;
using Grasshopper.Kernel;
using Rhino;
namespace LayerTestComponent
{
public sealed class LayerAddTestComponent : GH_Component
{
public LayerAddTestComponent()
: base("Layer Add Test", "LayAdd", "Layer addition testing", "Test", "Test")
{ }
public override Guid ComponentGuid => new Guid("{459E38B5-C9FA-4EE5-BE8E-398B3A405985}");
protected override void RegisterInputParams(GH_InputParamManager pManager)
{
pManager.AddTextParameter("Names", "N", "Layer names to ensure", GH_ParamAccess.list);
}
protected override void RegisterOutputParams(GH_OutputParamManager pManager) { }
protected override void SolveInstance(IGH_DataAccess access)
{
List<string> names = new List<string>();
if (!access.GetDataList(0, names)) return;
RhinoDoc doc = RhinoDoc.ActiveDoc;
if (doc == null) return;
for (int i = 0; i < names.Count; i++)
{
var layer = doc.Layers.FindName(names[i]);
if (layer == null)
doc.Layers.Add(names[i], Color.DeepPink);
}
}
// This here is key. It's just a made-up Guid that will never match to anything,
// but it makes this component expire when a new Rhino file is loaded.
public override void RegisterRemoteIDs(GH_GuidTable table)
{
base.RegisterRemoteIDs(table);
table.Add(new Guid("{EA4D5DE0-B79A-4E5B-B16F-2F4BDC1395C2}"), this);
}
}
}
Err… I barely know how to lace my shoes and scratch my nose while I walk, so I am sure I will do nothing of this, but Andrew…
Woa. But have you tried chewing gum and riding a bus at the same time? I’m still struggling with it. 
// Rolf
Still struggling with this issue @DavidRutten
Why not make this a component ?
If it is present , then whenever the rhino file is changed, the definition is recomputed.
If it’s not, well… it’s just like it is presently.
No frills…
Some have tried, but it doesn’t work.
I daisy-chained components from @Nick_Bruscia (here) , from @davidsmavrov (here) , and from @JoshD (here) and it works !
Thanks fellows !
Recompute GH definition when Rhino file is changed.gh (6.9 KB)
It effectively recomputes the GH definition when a new Rhino file is opened.
Piece of cake 
@DavidRutten it would be really nice to have a component for that in GH 2.
Well…sadly, the C# component works erratically…
By using the current file path and a timer + Levenshtein distance, I get a more reliable trigger :
Recompute when new file is loaded_more reliable.gh (8.1 KB)
Hell, it would really be nice to have something clean for that purpose…
I’m planning to write one. Though I don’t know why your C# component isn’t stable
