I’m new to DesignScript, so bear with me. I find examples of usages online, but I have a hard time finding documentation to further explain what I’m seeing. Yes, I have pdfs for DesignScript Guide and Documentation.
In this case, I think I have understood how to use __Apply and maybe __ApplyList, but I’m not getting the results I expect. I have googled for __Apply and __ApplyList but have come up with nothing. Again, just people using it, but it’s not in the DesignScript Guide or Documentation that I can find.
Anyway, see the Dynamo script I’m working on. I am trying to use the Dynamo node String.Contains within the DesignScript code. As you can see, the two lines using __ApplyList are returning null. That’s the first question. What am I doing wrong there. I tried with __Apply first and got “Function” in the Watch nodes.
What I need these two lines to return is a list of boolean values for each item in the list passed to it.
I then need to use those two lines for the output of line 5 to then use in line 9.
If __Apply and __ApplyList don’t or can’t work here, is there a substring function in DesignScript that I can use instead of the String.Contains node?
@TheMattatonAP I am also a novice so maybe I’m not understanding what you’re asking. Apologies if my answer is incorrect. However, I’m trying to be more active in the community instead of lurking and can’t do that and not make mistakes in the beginning. Why not use DSCore.String.Contains function? I couldn’t find any information on what _Apply or _ApplyList functions come from to help debug your issue. I would say make sure that “KEY_Door UG Letter” parameter is a string type otherwise you might need to convert to string before you use a string function.
Thanks, Peter. Nice to know other DS newbs. Although you knew about DSCore.String.Contains, so you’re ahead of me.
I see people using __Apply to use Dynamo nodes as functions in their DS scripts. Pretty cool. I just can’t find any documentation on those methods.
But, yeah, DSCore.String.Contains worked perfectly. Is it safe to say that there are a ton (if not all) of out-of-the-box Dynamo nodes that are mirrored in DS?
Still curious how __Apply works, but this solved my problem!
Thanks!
I can’t say if all because I haven’t tried them all but I’d assume yes all OTB nodes having a dot notation format. If you don’t know about Node to Code command or haven’t spent time with it. I’d say play around with creating scripts using nodes then converting them to code it will help you understand the dot notation code. See below.
Ah yeah. I knew that was in there, but I haven’t done it!
I’m much more comfortable with traditional code than visual node-based programming. I need to dive into Python, but that’s another topic altogether!
I think the biggest hurdle to doing more things with DS is understanding the lacing syntax. I have a screenshot of the different lacing methods, but haven’t messed with it yet!
Personally, I think the learning curve is simpler just jumping to Python. DS is limited to just Dynamo and documentation and examples are sparse. Where Python code and examples are everywhere. I’d rather write a python node than use DS or an imperative block. I can also make the node more robust and reusable with python code than other techniques.
I hope that the future versions of Revit more fully embrace Python - because well - it is fast and simple to write and deploy. Compiling C# over and over was always such a pain for anything other than a major application.
Python has been on my list for a while. I’ve used PHP and javascript for years, but Python would be very useful in my day-to-day.
With Python, do you have to interface directly with the Revit API to do what Design Script does? I’m over-simplifying there. I know Python can do much more. I just know Design Script is more directly tied to Revit whereas Python is independent. Wondering how Python “connects” to Revit.
Thanks for the input! Makes me more determined to get into Python!
The Python behind Dynamo/Revit is IronPython and that is tied to .Net. So it is just a matter of referencing the Revit libraries and you are off and running. As an example.
import RevitServices
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager
doc = DocumentManager.Instance.CurrentDBDocument
uiapp = DocumentManager.Instance.CurrentUIApplication
app = uiapp.Application
uidoc = uiapp.ActiveUIDocument
mySelection = uidoc.Selection.GetElementIds()
myElements = [doc.GetElement(e) for e in mySelection]
Writing a user friendly UI is simpler in Python. I can write the code so users can grab stuff willy-nilly and then filter out what isn’t relative quickly. Or use FilteredElement collectors to grab items much faster and more comprehensively than with the Dynamo tools.
I tend to use Dynamo as more of a development tool than a solution for running code. I deploy in the office using pyRevit which is supper easy to manage in a multi-use environment with limited administrative rights on the users workstations.
So I might use Dynamo’s transaction manager when I’m roughing something out, but then switch over to Revit’s transaction manager, so my Python can run outside of Dynamo. I don’t use custom nodes of any sort - so end users don’t have to install or track down anything. For this I use/write my own Python code. I also use the pyRevit dialogs for the same portability reasons, rather than Data-Shapes.
With that - my pyRevit is using both *.py scripts and *.dyn scripts. Just depends on complexity and time. The straight Python always runs faster.
There are some odd pyRevit and IronPython things you have to get used to. But that’s no worse than any other Revit oddity.
And I hate the SharpeDevelop tools built into Revit. They really should revert to the VisualStudio for Applications like back when.
Currently, I have a slew of Dynamo scripts I have put together and we use Dyno to make a custom ribbon connecting to the dyn files. I used pyRevit for this in the past, but it was SO slow and I ran into issues with certain scripts not closing, so when they were run again, there were some nasty side effects. Dyno has been great and is faster. But yeah, I use DataShapes UI a lot for user interaction. It’s clunky, but it works.
That said, I would love to know enough Python (and the Revit hooks) to be able to port all that over to Python/pyRevit. Seems like a much cleaner solution. Did you learn Python prior to using it with Revit, or did you learn it for Revit use? Any favorite places to go to learn Python specific for Revit use?
I closet kinda hate Dynamo and visual programming in general. It feels so limited. I hate that ALL the nodes have to run, error or not; that I can’t use a simple ‘if’ statement to determine if an entire section of the script should run; that it’s so hard to get a portion of the script to WAIT for the output of another portion that is running concurrently. I don’t have these issues with good old traditional programming.
Your Dyanmo issues can be fixed with:
engine:
clean: true
in your Bundle.yaml file.
This forces Dynamo to close after each run. It is slower of course to load and start the script, but eliminates the issue of scripts not closing - which is the default.
But for slapping buttons out for staff to hit and go - you can’t beat pyRevit.
I started with VBA way back. Moved to C#.
Then to Python and now Dynamo is in the mix. Mainly becuase I don’t have a good editor for code on my work desktop. And sometimes a graph is quick and easy and all I need.
Implementation and distribution of Dyanmo scripts in the office.
We’ve drifted from the original question at this point which was DesignScript language and I suggested that Python would be better in the long run.
Look into using and building functions (what you are doing inside of the IF statements in textural coding) instead of iterating over the list with the out of the box lacing. Passing null values will be faster though.
A code block consisting of [a,b][0]; will pass the value of A after B and A are returned. Not a thing you have to worry about in textural coding, but in textural coding you have to implicitly deal with your data structure for everything which can be problematic and time consuming for the uninitiated.
Overall I get where you are coming from, generally this sounds more like you “prefer to stick with what you know”, something we can all appreciate. Keep trying stuff out and growing as the more advantages you learn of each the better off you’ll be in the end.
Towards that end we had a nice community conversation highlighting Design Script a few weeks back. Worth watching as there is something in there for everyone.
Well…what? I swear I have asked and searched this question multiple times and have come up with nothing. In fact, I’ve seen answers that explicitly say this can’t be done.
So, this will actually PREVENT the nodes on the other side of it from running depending on true/false? Or will the nodes still run and just error out because they didn’t get the input they wanted?
It’s like I’ve always said about learning anything, “You just don’t know what you don’t know.”
Agreed, wholeheartedly! These forums have certainly been invaluable and I have successfully built a bunch of tools most of you pros would laugh at ( ), but they have really transformed a lot of the processes here in our office. So, as much as I don’t “get” visual programming, I can’t say it’s fruitless by any means. I have learned a ton and am still learning, obviously.
