Updating UserObjects - How to update other instances?

Grasshopper Developer
1

OK, so when I design a UserObject (saving it as a UserObject) and use it in different definitions, and then in some new definition I find that I need to upgrade the UserrObject with some additional code;

Q: how do I make sure that all prevously used instances of the UserObject are updated when I overwrite the UserObject (with the same name) on disk?

I tried to capture the ComponentGuid of the “original” UserObject and attempted to “put it back” into any instance version of the UserObject, but it seems the ComponentGuid is readonly.

Component.ComponentGuid = "blah-blah-fff5-4c44-a8f5-blahblahblah"; // nada success

Any ideas about how to automatically keep new & old instance up to date?

// Rolf

2

If your user object is a cluster:

internal static void SafeInternalDocumentModified(GH_Cluster cluster)
{
    // TODO: linked file is not correctly processed

    var baseDoc = cluster.OnPingDocument();
    if (baseDoc == null) return;

    var family = baseDoc.FindClusters(cluster.DocumentId);
    if (family.Count == 0)
        family.Add(cluster);

    // LooseChunk is used here for better performance
    // GH_Document.DuplicateDocument will be slower if you have 3 or more same-type cluster.
    var modifiedDocument = GetInternalDocument(cluster);

    var docCache = new GH_LooseChunk("Document");
    modifiedDocument.Write(docCache);

    foreach (var current in family)
    {
        // Mac version Grasshopper doesn't implement GH_Document..ctor()
        var newdoc = NewEmptyDocument();
        newdoc.Read(docCache);
        current.UpdateDocument(newdoc);
    }

    family.ForEach(x => x.ExpireSolution(true));
    baseDoc.DestroyAttributeCache();
}
3

OK, thanks, very interesting!

However, I typically have most problems with my C# components, which I give some period of time for refining before making VS versions of them.

// Rolf

4

Perhaps sidestep these problems and start writing your components directly as part of a plug-in in VS… There is no better moment than right now. Delaying means doing double work, especially when you start working all kinds of kinky hacks in script components.

IMHO.

5

Mmm… this thing https://www.food4rhino.com/app/codegencs2vs does the job pretty well.

So I do have my own “RIL” plugin since long, but many quick hacks emerge and… It’s slow to test in VS when there’s need to restart Rhino and… no. Although VS is “better” (agreed) the roundtrip is not very rapid.

// Rolf

6

The roundtrip isn’t very fast, no. But I like to think that this gives time to reflect on code and mechanisms, which sounds like a better thing than making a huge amount of random changes in a short amount of time, hoping it works better this time…

But this is of course also a personal taste issue, and how people work (:

7

Well, I understand your argument. But primarily being a GH user myself is the perspective I’m reasoning from in this case.

Being a user is also why I prefer testing a number of use cases before making “permanent” VS versions. Over time different usecases often reveals the need for refinement, more functionality and improvement of “resilience” (unexpected usecases reveals weak spots, lacking documentation and …

As a GH user I don’t very often start from a well defined list of requirements from other domain experts already having tried different ways to solve (a group of) problems. Which is more ommon for developers.

OK, it gets lengthy this but …

Well, since the perceived need for a component raises out of concrete use cases I want to let such components try to stand the test of (some) time before littering the permanent library with component versions which at the time seemed to be such a good idea.

After spending some time trying to solve a problem, the problem may turn out to belong to a generic group of problems which would be better served by more generic components. In these cases UserObjects can simply be deleted from the folder without killing other definitions using instances.

In any case, rapid growth of code libraries isn’t necessarily a sign of improvement. If a library grows very fast it may instead be an indication of that the thinking behind isn’t generic enough.

Library rot. :wink:

// Rolf