Expanding Properties in GH (Mac)

Properties written to Base Objects appear in the viewer correctly, but bringing them into GH (Mac) they all render as the, I guess, .NET primitive type name… ¯_(ツ)_/¯

System.Collections.Generic.Dictionary`2[System.String,System.Object]

Is this a me problem in how they are written or the GH plugin on conversion?

1 Like

Interesting :thinking: I’m just doing some cleanup in GH today so I’ll check this. Could you send me a file to reproduce this quickly? or a stream :smiley:

1 Like

Thanks! I noticed your Properties object doesn’t have a speckle_type, and I think this is causing the deserialiser to interpret it as a Dictionary instead of a Base object.

Can I ask how are these objects created? Through our .Net SDK? :slight_smile:

Anyway, I’ll look into how to handle this things better in our side too.

Yes, this is through .NET.

Interesting I was simply adding Properties as a dynamic property to a Base object, but I can relook at that.

1 Like

Interesting indeed! As far as I remember, any Base object should be serialised with it’s speckle_type set.

I’ll ask @dimitrie since he may know more about this than I do. But I fear this may be the case. Whatever you find out let us know, as it seems something we can improve on our side one way or another.

Random suggestion, have you tried detaching the properties object?

Base elementBase = new Base();

...snip...

Dictionary<string, dynamic> propDict = new Dictionary<string, dynamic>();

...snip...

elementBase[ "Properties" ] = propDict;

Perhaps that was being overly ambitious for serialization, but the properties make it as far as the viewer even if GH struggles.

If there is a better way to walk through that Dict to “Basify” it, I’ll change happily.

1 Like

Aha!

I think its a mix of you forcing our limits and us not having a clear strategy when it comes to Dictionaries (I know dim would like to rewire the whole base object thing if he could)

The way I see it, this is not really our fault :sweat_smile:, as it’s Grasshopper the one that lacks Dictionary support. But that being said, I would gladly add a conversion from Dict to Base on these cases, to prevent the user from ever experiencing this on the GH side.

I’m assuming you’re happy with your dictionaries deserialising correctly, you just wish we’d handle them better. Right?

I’m not wedded to writing Dicts in that way at all*. Like I said, I’ll take direction for an alternative (better) way.

The way I see it, this is not really our fault :sweat_smile:

tncZqLR

* It worked well enough for a hackathon.

1 Like

Lol, i would indeed! haha go complain to the Rhino forum :rofl: hahah

Now seriously, if you want to avoid this from your side right now, you could replace your Dictionary<string, object> with a Base object instead, that should make the whole thing work like a charm!

Anyway, its nice that you bring this up, we’re going to try to improve the developer experience and all this small cases do matter! :raised_hands:t3:

I guess that worked :smiley:

Things I Learned: Using the Dict allowed invalid prop names into the objects - the viewer didn’t care

    Base propertiesBase = new Base();
    foreach ( KeyValuePair<string, dynamic> entry in propDict ) {
        if ( entry.Value == null ) {
            continue;
        }
        propertiesBase[ SanitizePropName( entry.Key ) ] = entry.Value;
    }

    elementBase[ "Properties" ] = propertiesBase;
    return elementBase;
}

public string SanitizePropName ( string name ) {
    // Regex pattern from speckle-sharp/Core/Core/Models/DynamicBase.cs IsPropNameValid
    string cleanName = Regex.Replace( name, @"[\.\/]", "_" );
    return cleanName;
}

Refactored to do away with the Dict altogether, and nested Base objects per property category.

Now with added psychedelic colours per parameter!!


For what it is worth, I wasted a bunch of time debugging this only to discover you cannot add a dynamic property to a Base object called “Item” :confused: renaming as “NavisItem” fixes.

4 Likes