Since thread necromany is frowned upon and asking a question that’s been asked countless times before deemed the lesser of evils…
Adding Shared Parameters to family files.
Off the back of this:
and having the pre-requisite Orchid & Rhythm packages all installed - I thought this (long overdue) attempt would be a no effort at all copy & paste job. But alas.
What’s weird is - the script runs, no warnings, it even creates backup files - but the principal intent of the script - the actual addition of a parameter? Nothing, nada.
seeing as I’ve stumbled across far too many dead-end “solved” threads in my time I’m going to forfeit any kudos (lol) to add the solution as an underline here…
well, one thing that it could be is that theres nothing enforcing the sharedParameter.Add function to be called before the document.close node … maybe try using a passthrough codeblock to enforce the order - though I would expect an error if the document was closed when trying to add a parameter - but who knows.
oh! I didn’t notice before, but that node’s inputs are not fully set and it’s returning a function (partially applied, not executing) - it looks like you need to pass a bool to the reporting input, or one of the other inputs that may not be using a default value.
Needs a parameter type at a minimum. Also there may be a difference between an Orchid document and a Rhythm document. Many of the nodes in Orchid rely on a custom duplicate data type which fails if given the OOTB version.
Huzzah! Great spot - I was relying on the default values in.the.absence.of.an.input.of.my.own - but missed the node’s “type” input did not have a null - so guessing-at-syntax-at-this-late-hour used “Text” w/
got me my SP injected into those families, open/save/closed and backup files skipped! I’m just going to leave the Clockwork passthrough in there regardless cos’ I hate fiddling with things that work.
{He says}
Now to figure out how to throw LOADS OF SPs with different data types from different groups* into LOADS OF FAMILIES (insert manic laughter)
Guessing at the lingering questions on the markup: Reporting is a Boolean asking if the parameter is a reporting parameter or note. Likely false in most cases but there will the a need for it someday.
For managing the multiples, test levels closely. Also building the ‘type’ and ‘group’ into the excel sheet will help (doubly so if you can quickly check values against the available options prior to sending to Dynamo).
I’m now well passed rum-o-clock looking at this stuff so playing fast and loose with (offline) content, but duly noted
re: list-levels (thems-my-nemesis) yes, next (personal) challenge, but thread wise? I think we’re dead - still, I hope that even 1xSP-@-a-time will save* me and (I imagine/hope) many others: a fuqtan-o-time.
*not to mention those dropping $10+ on “addins” to do this… ick.
Great spot - I was relying on the default values in.the.absence.of.an.input.of.my.own - but missed the node’s “type” input did not have a null - so guessing-at-syntax-at-this-late-hour used “Text” w/
