This is just a thread to see what people recommend as the ideal method(s) to bypass the quirks of element bindings. I appreciate every now and then the are useful in principle, although more often than not produce undesirable outcomes - generally when running scripts from Dynamo itself (not Player) that create new objects.
The main issue I have with them is if you are running a script creating objects in sets they become impractical. E.g. I was working on a facade the other day and ran it one surface at a time, lo and behold each time the last set of panels get unmade due to bindings. Even worse, sometimes when closing the script they would be unmade also. I understand why this is happening, I just donât agree with it. Itâs incredibly unintuitive for a less experienced user, and the amount of topics with this issue historically backs this up. They are one of a handful of things that I think easily turn new users off Dynamo once they hit them, as explaining why they exist and how to deal with it presents a wall of text to read, or a very abstract description at best to help them âwatch outâ for them.
Rhino Inside Revit has a lovely way around this in the right click options for creation based nodes (appreciate itâs not the same as Dynamo), where the user can nominate to replace or create new elements on each run. I find myself wishing for this in Dynamo quite often, even if just as an opt-in like RIR (by default it binds).
Anyway /endrant⌠on to some ideas.
Some methods Iâve used to deal with them in the past are:
Delete the binding related node, make a new one
The same, but keep a copy of it off to the side hooked/ready to go
Remove them using a text editor in the script file
Various tools to flush them, e.g. data shapes
Only run via Dynamo Player
Run the creation step within a Python script
At the moment I tend to use the last option as itâs the only one that is dependable and easy to deal with on the fly in Dynamo itself, but wanted to make sure there wasnât some super obvious option that exists. I do recall a âturn off bindingsâ option being mentioned or prospected in/for more recent development updates.
Most graph executions are not in the authoring environment - as in people write the graph once and run it many times. This is likely to be even more true in the future (make no purchasing decisions). So if when you are done and ready to hand it off for bulk use, clear out any bindings and run via player there are no issues.
But during the process of authoring graphs, binding is a must. When I was in support I would see/review one model a week where Dynamo was blamed for making things unstable, only to find that the project had so many duplicate element warnings that the model became unusable. Two seconds after getting the graph usually Iâd find the Python node with binding suppression set up⌠bindings just prevent this and as such are a good thing.
That said if after you finish authoring the graph you just want to remove any bindings and prevent them from ever coming into play, just leverage a Function Apply node or a List.Map node and not only will you block the binding but also suppress any warnings.
I appreciate why bindings exist, and not proposing they should be done away with or defaulted off - I know youâve dealt with a lot of grumbles in this area and your main post on them convinced me theyâre necessary as the âbase caseâ of how Dynamo behaves.
I just find more often than not that myself and other colleagues run into more scenarios where they can be a hinderance. We take advantage of them whilst maintaining set facades, groups of objects etc. that we know will need to be refreshed often so theyâre useful at times. As comp lead where I work I spend a lot of time explaining why they exist vs getting appreciation from my colleagues as to what they are useful for. Iâm trying to defend Dynamo where I can from criticisms that those newer to it have of it, in the hope they donât run back to Grasshopper and spread misinformation about the platform internally.
Just wanted to see if I was missing an intended way to bypass them. Happy to keep using the Python workaround, but it feels unintended when I take that pathway. If it is what is, then I can work with it, just wanted to endorse the best approach inhouse moving forward as we get more Grasshopper users in Dynamo not used to this behavior. When working in a design manner, Dynamo Player isnât an option for us as we want to tweak/run in session - bindings are useful here until we want to test them elsewhere and keep another set of objects such as a design option. Just feels a bit too âunder the hoodâ for me.
Function apply/map is a good tip, have used it at times although it does have some time additions to the run time I think, thanks!
In my experience it will prevent binding from occurring as the node that would usually hold the binding (e.g. familyinstance.bypointandlevel) is used as a function to be applied vs used as the node itself. Function apply doesnât seem to store bindings, although in my experience it will run slower, I assume as itâs having to do more work to line up the inputs to the node provided to the function. I use this node to supress null producing errors also, function.apply will just return null instead of warn the user about it.
how exactly use Function Apply node or a List.Map to beat binding? factory seems like this feature so much âŚ, just like Revit shared coordinates stuff, âhot topicâ for decades âŚ