Dynamo for Software Developers: C#, Python, and More—Workshop - Part 3 of 4

PRESENTER: Hello. Welcome back, everyone. So where we left off at the previous session, we finished our C# library, and it went Kaboom. It's not meant to do that. It's a mistake I did, not you guys. So it's me not you. So let's just fix it real quick because Tom will need that library for this next session he's doing with you. So I'm going to get you guys to change two lines of code real quick before we move into the exciting zero touch session, OK?

So if you just follow what I do to make sure that you guys have a correct version of the library. And go to the solution again. And under Geometry U tools, if you find line 26 where it says-- sorry, 25, where it says double step and there's an expression there. Instead of that expression, if you could just type 0.1 that would be helpful.

And just remember, if you don't do this code change, the next session might not work as intended because we're trying to generate the layout in this one and use it in the next one. So change it to 0.1 here. And then, go to the desk architects class, I think that's where it is. No, the desk arrangement class. And this desk count is actually incorrect at the minute. So you just have to swap the 0 and the desks count between each other in respect to the semicolon.

I always forget the order they're in. And I just put it the other way around. So after the question mark it should be 0, and then semicolon. And it should say this.desks.count.

And whilst we're in here, make sure that in the desk architect class you have this line that says desks.adddesk, which was what we were doing when we were coding.

AUDIENCE: [INAUDIBLE]

PRESENTER: Yes, the desk arrangement one. So now if you have all made these code changes, if we load it up in Dynamo, and we have the same workflow we had earlier, we're just making a rectangle, a surface from it, then we use the layout desks on surface. We're going to come back to the code in a second if you need to see it again. If you run this workflow now, you'll see it actually creates desks. And you can see that the desk arrangement was created at a specific date time. And it returns 121 desks, for example.

So if we go to the desk arrangement class and we actually scroll down and get the desks from the arrangement, when you run this, you would get 121 individual desks, which you can go back to the business side of it, go to desk, and interrogated for a, for example, origin. So you should get 121 Dynamo points now.

So you can see how our classes work, and we can decompose it into these things. Yes.

AUDIENCE: [INAUDIBLE]

PRESENTER: Yeah, I'm doing that now. So on the desk arrangement, it's line 21 that needs to be changed around a little bit. And the one before is in Geometry utils, line 25. Instead of an expression, it should just say double step is equal to 0.1. So remember how I gave you guys a hard time for not forgetting to check for things like dividing by 0? I was dividing by 0. Somehow. Don't know how. Yes.

AUDIENCE: [INAUDIBLE]

PRESENTER: Saying you can't open it? Failed to import library.

AUDIENCE: [INAUDIBLE]

PRESENTER: So if you get failed to load library in Dynamo, you need to go to Dynamo settings, manage paths, and make sure you remove the last path, the one that points to our DLL. Close Dynamo, start it again, and then import it again. This is a fairly new change in Dynamo where it remembers where it imported it from. So you need to make it forget it. I'm going to come in a second.

So everyone done these changes? All good?

AUDIENCE: [INAUDIBLE]

PRESENTER: So to import it into Dynamo you just go file, import library. And then, you find the DLL, which is in data sets, you'll find the session. It'll be-- if you've moved the folder to your desktop, it'll be on your desktop or wherever you're doing this from. If you go to C# fundamentals exercise four-- I'm using the complete one-- you go to the BIM folder, and there's a few more folders in there. And finally, you get to the Dynamodev.yellow. That's the file you're after.

So that's it. I'm going to hand it over to Tom now. Studio for a second? You can just swap it out when you need to. OK, anyone else having issues with the code? Have you tried running it inside Dynamo? Does it work? Sorry?

AUDIENCE: [INAUDIBLE]

PRESENTER: You go to Dynamo settings, yes. So if you guys have built the solution and then imported it into Dynamo and then you try to build again, make sure you have Dynamo closed.

TOM: And Revit.

PRESENTER: Because otherwise, we won't be able to actually build the solution again.

TOM: [INAUDIBLE] OK. Do you want me to start? OK, so this afternoon then we're going to be looking at zero touch nodes. Zero touch just describes the process. So this session then is, basically, going to be looking at what you've done in the previous session with Radu. Where of course, a lot of what he's done is really quite abstract, and there's nothing tangible that we've developed so far. You can actually see. Which can be, I guess, like a bit kind of alienating if you're new to programming.

So this next session is not only going to turn a lot of already used verbs in the last session into something more tangible in the form of Revit instances, namely desk instances within the model. But also, we're going to be looking at how we can actually create a set of zero touch nodes within Dynamo, and the whole process for actually setting that all up.

And I'll also explain how dynamic actually consumes compound libraries. And that process of importing those DLLs that you've already created so far today. And the generation of nodes in the library at the click of one button is what is known as zero touch. So zero touch really just describes the process of importing a compiled library written in C# to generate a library of nodes without you having to do anything other than just declare your classes and make them public. That's literally all you have to do with zero touch.

So [INAUDIBLE]. OK, so the plan for today then will be the following. As I said, we're to continue building more ready than the last session, we're going to use all the data, which we've generated using your desk class to output Revit instances. So basically, what we're going to do by the end of this session is the following.

We're going to have a set of nodes, called zero touch nodes, that are going to be able to compute the egress distance from each desk to a given point. I'm actually going to use Revit's brand new built in path of travel class. And this class just processes from two points an escape route through your building. And it will detect things like openings, i.e. doors, and work how best to create path to travel to wherever your target point is.

And we can actually visualize this. In our case, just using a set of Dynamo curves, which you can actually see on the screen now. So you notice that as I move my exit point, which is based on the end of that line, what it's going to do is it's going to recalculate the path of egress for me. And our libraries, which we're going to generate, which we'll then convert into nodes when we actually do the zero touch import, is then going to redraw all of these path of egress for us.

So you can see here with those six desks, and each of the six desks now has a path of egress. So by the end of this session, then, you're going to create the following. You're going to create a class called desk creator, where it's going to have one static method which will be called generate. What that method is going to do is it's going to take your desk assembly object you did in the previous session. It's going to take all the desk objects out of that assembly, and it's going to convert them into actual Revit desk instances inside your model.

After we've done that, we're then going to build two other libraries. One of them is called egress checker, with one method called get results, which is also going to be static, which is this method here. And this method returns a list of egress results, which is also going to be one or the other classes you'll be building today. And that class, again, it just built on some of the concepts which you learned with Friday's session this morning, which is declaring our class. Declaring a constructor.

We're also going to be looking at access modifiers so you guys can get a better understanding of what public, private, and also internal means. And once we've done all of that, the end result will be a range of query nodes under egress result, which enables you to, for example, check things like the path, also to identify which instance it refers to. So if you want to know out of those desks, which we're looking at inside the Revit model, which one of those desks refers to which path. You can do that as well just by simple index matching.

And then also, working out whether the egress result is valid. And we can specify what the maximum egress distance is. So perhaps in a real world context, maybe if you had some sort of regulation about minimum fire escape distances. And really, you could actually use this for anything. I mean, imagine if you're an MEP engineer, and perhaps you're trying to optimize ducting or pipe work in the building. You could even use this path of travel you even for that.

So when it comes to programming, try to think outside the box. Because there's many techniques inside the Revit API that enable you to do all kinds of things. And is really limited by your imagination. So today, we're going to show an example using desks, but as I said, you could actually apply this part of the API to many different problems within construction. All you've got to do is just think about it. And then, just use your creative intelligence.

OK, so let's get started then. First of all, just to reiterate what zero touch means. It literally means this. Where you see add ons inside of Dynamo, if you click on that button, it will ask you to find a DLL file. When you find the DLL file, so in our case, we're going to be generating a library called zero touch nodes. When we locate that file, I'm not going to find it on my computer, but if we find a DLL file and select it and click open, Dynamo will attempt to read any public class, any public constructor, any public property, and any public method, and it will convert those into nodes inside the library.

And then, you can place those nodes on the graph. And Dynamo will do all the hard work for you. It'll work out all the input ports, all the output ports, it just renders everything for you. That's why it's called zero touch. Because it's minimal effort. You just write your code, declare your classes, as I said, put whatever kind of properties and methods and constructors you want inside your classes, and then you just import it. Sure.

AUDIENCE: [INAUDIBLE]

TOM: All right, well, Python you can't actually create a compiled library. So the process of actually importing a library doesn't apply to Python. With Python, you just create a custom node using a [INAUDIBLE] file, and then you can just load those in. So there's a slightly different technique, but really the end result is the same thing. It's a set of custom nodes in the library. But yeah, the languages do have slightly different techniques for the generation of that library.

But for C#, it's zero touch import. Yeah, that's why I actually-- typically, when you hear zero touch mentioned, people usually say, I'm building a zero touch node. I'm being really pedantic here, but technically, that's not correct because it's actually describing a process of importing a library. But I mean, I guess there's no harm in calling it a zero touch node because it just means a node that's built in C#.

OK, so what I'd like you to do then is fire up Visual Studio 2019. And we're going to be opening up the zero touch nodes library. And you'll find that in the data set. So if you just go back to the [INAUDIBLE] developers data set. Find S3 zero touch. And we're going to be using the library which has got a start and end to it. So if you see a workshop template start, we're going to be working from there.

When you find zero touch nodes S there, if you can just open up that file. And when you open it, it will just be a very basic and minimal kind of project. And we're going to start writing all the classes. What we're going to do as well, just based on the progress which we've made so far this morning, and I want to avoid this mad rush at the end. I'm actually going to ask you to just literally drag and copy some of the classes straight over. But it's going to focus on building maybe two or three classes in today's session. So it's kind of manageable within the time I've got.

And that way, you're not going to miss out on anything. And crucially, you'll understand more of these concepts that we've been conveying for most of today. OK, so--

AUDIENCE: [INAUDIBLE]

TOM: Yeah, hang on. Is that better? With the Solution Explorer, I don't think you can make this any bigger. [INAUDIBLE] the Solution Explorer. I don't think you can make that any bigger, can you?

PRESENTER: Change the resolution.

TOM: OK, I think that's better. OK, so let me just remove this because that shouldn't be in there. All right, so what you should see is the following. You should see zero touch nodes solution at the very top. Properties and then references. And in references, just check if you've got the same problem I've got. If you see all of these rectangles that are yellow, just highlight all of those references. And what is going to remove them. Or what happened back in now just so it's not a problem.

And actually, it's probably better that we do have them because then you can see the techniques that we actually use developers for loading in the libraries. I'm going back to this morning's session with Python. In that boilerplate, you've got all of those imports, which load in things on the Revit API, and also Dynamo's libraries as well. There is an exact equivalent within C#, which I know Radu has already showed you. And that's just those using statements at the top of your files. So those using statements are the equivalent of import statements within Python.

So you could see the correlation between languages and why, really, if you learn one language, you've pretty much learned all of them. So I mean, there are nuances between the two, but really that's very true that all the languages, they all have very similar concepts. So that's why it's always worth mastering one language. Because you'll tend to find any other language. That'll be a lot easier.

OK, so to get things started then. The first of which we're going to create is that node which basically takes the desk assembly, the [INAUDIBLE] ability-- sorry, the desk arrangement object, that is going to read all of the desks that are in the original object. We're also going to to provide a desk type and a host level. And then, this node is going to help a bunch of Revit family instances as desks inside the model.

OK, so first of all, we know we want to create a class then called desk creator. So in Visual Studio, let's create a new folder to actually store this new class in. So where it says zero touch nodes just right click. Add new folder. And this new folder is going to be called family instance.

And inside that namespace-- so even as a folder, that will actually translate to a namespace within C# by default. But you don't have to use it if you don't want to, but we will today. We just want to add a new class. So right click on the folder, add, and then class. And this class is just going to be called desk creator.

OK, so the first thing that you want to do is, actually, just write a method. We don't need any constructors or any properties for this class. Just as a quick note, by default, every single class which you declare within C# always has what's called a default constructor. So you cannot declare a class without a constructor. The C# compiler will generate a construct for you, a default constructor, which is noteworthy for zero touch import.

Simply because if you do not declare your own constructor and you import this library, you'll end up with those constructors appearing your library. And they're just redundant nodes. They're going to do nothing because C# will auto generate the constructor for you. I'll actually show you as well, and then I'll show you how we just resolve the issue. Because it's a simple thing to do.

But it is just worth noting that you will see an additional node appearance on your library. And if you've done this before and you wonder why, it's because C# is doing it on your behalf.

OK, don't forget, if we don't mark our classes public, then Dynamo can't see it. So that's the next in which we need to do. So we should say public class desk creator. And the method which we're going to create, and I said, it's just one method for this class. It's just going to be called generate. So again, you notice that we mentioned this morning about being quite concise with the names of your variables. And that really extends to everything which you declare within your program. Name spaces, classes, methods, properties.

Try to be descriptive, and just make your code essentially self-describing. If you can achieve that-- and there is actually an art form to it, I would say that. Trying to think on the fly of a sensible name for your entire code base, it can be a challenge at times. But yeah, try to spend as much time practicing that as actually practicing the code. Because as I said, it can be a major barrier to your learning curve if you don't declare things in a sensible fashion.

OK, so we've got this creator, and we're going to create a new method called generate. So first of all, we need to decide on our axis modifier. So in most cases, we want Dynamo to see it. So it should be public. We then also need to add an optional modifier. So you've got axis modifiers and modifiers. And modifiers, again, they just change the behavior of whatever it is your declaring. So in our case, it's a method. And we actually just want to make this static.

So if you remember, when Radu was explaining what static meant, he meant you can only create one of a certain thing. There is a bit of a caveat there in the sense of if the static method returns instances and objects which aren't our method well, then it cannot return more than one object. But just remember the technique here. If we declare a public method inside our type-- so our type is desk creator-- and we make that static, that means that to call our method, we have to declare desk creator as the type, the operator, and then our method.

So to put it into Dynamo terms, all that means is when we place that node on the graph, we do not need to provide an instance of our desk creator. We can just place it on the graph, and then all we need to provide is the inputs into our method and nothing else. So if we use static, it means that we don't have to provide an instance of our own type. So our own type, in this case, is desk creator.

So we just leave it as static. We then need to decide on the return type. And in our case, it's going to be a list. Lists are always declared in C# with a capital L, and the chevrons. And inside there, we need to determine the type of element that it's going to return. Now, we are going to be returning wrapped Revit instances. So again, the concept's the same as this one with Python. And this is just going to be a list of family instances. But in actual fact, we could literally just use the superclass that Dynamo uses. The Dynamo element class.

And for that, we're actually going to use a using statement. And we're going to explicitly define what I-- or rather, what this alias refers to inside Dynamo's Revit nodes library. So what I'd like you to do is just type using at the top. Whenever I use an alias-- and why you would use an alias, by the way, because I'm kind of jumping the gun here-- is to avoid namespace clashes.

So one of the issues in which you might find if you're say referencing the Revit API and the Revit nodes library, which is Dynamo's wrapper class for all the Revit elements. Because the names of types are the same, for example, [INAUDIBLE] war class, Revit API also has a war class. When you import both libraries, the compiler can't determine which of those types you're trying to find. It will say that you've got an ambiguous reference. Because it's looking at both libraries. You're saying, look at this library, look at this library. It finds two classes with two matching names. And it can't work out which when you're calling.

So aliases are actually a really convenient way for you to directly say, look, if I ever declare this alias in my code, then I'm referring explicitly to this type. And other compilers [INAUDIBLE] knows what you're referring to. So whenever I'm defining anything out of Revit nodes library, I always precede the type with the word Dynamo. Then it's very obvious. So in our case, it's just going to be called Dynamo [INAUDIBLE] equals-- so we need to declare an alias. I guess we'll have to declare a variable. You just use the assignment again.

And we need to reference Dynamo's Revit nodes library. Now, you notice that we've not actually added any reference to that library. So right now, the compiler doesn't even know it exists. So we do need to go ahead add that. So we've got references, right click, and then add reference.

And then, click on browse. And you need to go to your C drive program files and then Autodesk. So you can see at the top here, that's where I'm at. And let's find Revit 2020. Go to add ins and find Dynamo for Revit. And what we're looking for is a DLL file, a library file, called Revit nodes. And you'll find that inside a folder called Revit. So you just want to go to add ins, Dynamo for Revit, Revit, and inside here we'll find a library called Revit nodes. And we just want to add that. And then just say OK. So Revit nodes should automatically appear.

And going back to our alias, so once you've imported that library, we just want to do the following. We actually want to explicitly reference a type from that library. Now, I'll just type it out. And then after I've typed it out, I'll do a comparison actually viewing the API from Revit nodes, and I'll show you what I'm actually doing here. So I'd just like you to type the following. Type the word Revit, and operator elements, and operator again, element, and then just do a semicolon on the end. And you've just declared your first alias.

So you could see that we've got a namespace that's-- which Visual Studio quite conveniently is highlighting for us. And as soon as we declare a type, it then changed the color. So we're saying this alias is specifically pointing to this class from this namespace. And the compiler knows where the namespace is because we've just imported it.

So if I just double click on Revit nodes, it takes me to something called the object browser in Visual Studio. An object browser is basically your looking glass into any API. So you can look at Revit API, [INAUDIBLE] any language which you import, you're going to find this [INAUDIBLE] this library. So if we just expand Revit nodes, you'll find that there's actually a namespace called Revit.elements. And inside there, there's a class called element. This is literally what we're pointing our alias. It's that simple. So we just define a namespace. Namespace in Visual Studio always those curly brackets. And then classes are always these funny orange icons which you can see here.

OK, so inside our list, we do Dynamo element because this is the return type of our method. And we can finally declare the name of the method. And then, as it's a method, as you know, we've always got to open and close curved brackets. That's how we always declare a method. It's using curved brackets. And in the statement body of C#, again, is curly brackets.

So [INAUDIBLE] body is beneath the method that we've just declared, and curved brackets defines the method itself. Your [INAUDIBLE]. Has everyone compiled it? Have you got backup in case they haven't?

OK, we now need to define the input parameters for a method. So these are going to be the input ports that appear on the node after the zero touch import. So this is how the mechanism of zero touch actually works. It will read whatever your input parameter inside your method. Whatever name you give to each input parameter becomes the name that appears on the input port on the node. And similarly, the output is also declared by the return type for the method. So that, again, gives you more insights into the mechanism of zero touch import and what it actually means.

So the first input into this method is actually going to be what you create in Radu's session, which is the desk arrangement object. So as you know, with C# being a strongly typed language, we always have to declare the type before we can declare the variable name, or in this case, the input parameter. And for this, it's just going to be called desk arrangement.

OK, when we are reading all the desks that are stored in that desk arrangement, which as you know, at the moment, are abstract. We've just declared this class called desk, but we can't see anything yet. But that's what this method is actually going to do. It's going to return a bunch of desk instances for us. For that reason, we therefore want a Revit type. We want a family type. So when we actually instantiate new desk in instances, that is going to require a desk type. A bit like when you're using Revit normally. If you choose a desk or any kind of family, you always have to decide on what type you want.

And it's no different when you're making Revit API calls. In actual fact, it's what you do manually within Revit is now just what you do when you actually program. There's literally no difference whatsoever, which is why the rule stands that if you can do it in Revit manually, there's probably about a 99% you can't do it in the Revit API either.

So the Revit API doesn't give you, necessarily, like special magic powers. Depending on, perhaps, the user. It's more a means of enabling you to just automate and turn a repetitive or complex problem into something far more simple. Because you're getting the computer to do the hard work for you.

So for this, we need to input a type. But remember the rule of thumb, this is going to be input from Dynamo. So we all know it's wrapped here. Everything that comes in from Dynamo is always wrapped. For that reason, it's going to be a rapped Dynamo family type. So we also need to define an alias for this as well.

So at the top, let's just copy and paste that line. We'll call this one Dynamo family type. And just get rid of elements on the end of that. The operator [INAUDIBLE] family type. So you notice the suggestions that we're getting from IntelliSense. It's just unbelievably useful. And this is one of the big-- I mean, I'll be honest with you. It's kind of a dilemma between say Python and C#. Which one is easier? Generally it's C# because it's more verbose language. It's got a more steep learning curve.

But the farther you can be in [INAUDIBLE] whenever you C#, if perhaps you're developing quite a complex program that has maybe many classes or perhaps is solving a very complex problem. Generally speaking, C# might be the better option than Python in those cases. But both languages have got pros and cons, and they're both great. So I would say, if any language there you want to begin learning, Python is a good choice. It's a really good language.

OK, so we've got done the family type. So let's just provide that as the next input. The last input is just going to be the level where we actually want to host all of our desks on to. And again, this is going to come from Dynamo. So it's rapped, therefore, I'm going to create a new alias. And I'm just going to call that Dynamo level. And we'll add the alias in just a second.

So you just do Dynamo level and then just call it level. And then, we'll just add one more user statement at the top there.

OK, so your aliases should look like this by the time you're done. You should have three aliases at the top. Dynamo element, Dynamo family type, and Dynamo level. And they should all point to these specific types from Dynamo's Revit elements namespace. And this namespace lives inside the Revit nodes and library.

OK, so now we can start actually writing code. So remember what the objective here is we want to take that desk arrangement object from the previous session. We want to access all of the desk objects that are stored inside that desk arrangement. And then from the properties that are stored on each desk, for example, it's got a location point, it's also got dimensions. So a width and a length. We want to use the information to then generate these family instances within Revit.

So the first thing which we need to do is actually go back to referencing that boilerplate from the Python workshop. So if you guys just launch Visual Studio, or if you don't want to launch it, simply go back to the sample files, find Python, and open up the boilerplate. Either one is good. And we're just going to copy some lines of code out of this boilerplate. So believe it or not, there's actually even some crossovers with what we use in the boilerplate for Python, and also what we would typically copy from the boilerplate into C# as well.

So if you just open up the boilerplate. The lines of code which you want to copy into your code is that very first line at the top there. Just the document. So if you just copy that and paste it in. Remember this is a strongly typed language. So we can't get where it is declaring doc. And then equals, we have to declare the type. So in our case, it's just going to be document.

Again, I've already showed you this. You'll get input-- rather, you'll get hints or suggestions in terms of what user statements you haven't added but might need based on what you've just declared. So we click on this. Just be very careful here. You need to pick the right one. You need to make sure that you pick the one in the middle, which is Autodesk.Revit.db.document. So just make sure you pick that one.

And the document manager is actually coming from another library that you get with Dynamo that we haven't added to our solution yet. So this is actually coming from the Revit services library. So inside references, right click, add a reference. We should go to find it within the same folder, again, we do browse. So you just click on browse and then look in the same location as before. So Dynamo for Revit. And just find Revit services and then add. And then OK.

And when you hover over it now, you should be able to find the correct namespace from the [INAUDIBLE] library. So once you've done all of that, you should have the following. You should have the user statements for-- sorry, user directives for the Revit services systems, which is basically enabling us to use the document manager.

And then also, reference to the Revit API itself, which is this using directive at the top here. Yeah.

AUDIENCE: [INAUDIBLE]

TOM: What about in Visual Studio?

AUDIENCE: [INAUDIBLE]

TOM: All right. That is because-- sorry, yeah I've jumped the gun there. OK, so it's because I've already got the library available. So you guys need to import the compiled library from Radu's session. So if you're seeing desk arrangement in red like what I've got there, you just need to add that library into your references. So for that, if you just do add reference, browse, and what you want to do is browse the BIM folder from Radu's session. So I'll just show you that on my machine as well.

If you go straight to exercise four and go to complete-- or rather, if you should just check your-- if you create your own solution, OK? If you go to the location, I just said, you're not going to find anything in there. So you guys want to compile your own solutions. And when you compile, you'll find it inside the BIM debug folder. So inside here, you should find a DLL called Dynamodev.dll, and you want to add that as a reference into you solution.

And Radu, have we got that library available in case they haven't-- they can't compile?

[INTERPOSING VOICES]

PRESENTER: It's on the GitHub page. And the C# Fundamentals. There is a DLL straight up on GitHub. I've just pushed it. So in case you need it, we can download it straight from there.

TOM: Has anybody not got access to that file? So you should looking for Dynamodev.dll. If you haven't got it, then just raise your hand and I'll show you on screen now how you can get that file.

AUDIENCE: [INAUDIBLE]

TOM: OK, great. So mine is out of date. So if you guys got it in there, that's great. Load that file in, and we're good to go. Thanks, Radu. OK.

Right, so once you-- let me just add my reference back in again. Once you add that, and then you should no longer see the warning on that type. You should be able to just find it without any issue whatsoever. OK. I don't think I'm going to need your file. I think I actually just removed that reference and lost it.

OK, so we've got the document object declared. The next thing in which we need to do is open up a transaction. I didn't actually explain what the transaction is for in the Python section, but we did actually use one. And again, we're going to just copy that straight from the boilerplate.

So if you go back to your boilerplate, and there's just two lines of code, which we're going to copy. And it's just going to be the ones which say transaction manager, ensure, and transaction. And the one below says transaction done. So I just want you to copy those lines of code, and paste them into your brand new method.

And I want you to see the issue with these hashes. Because C# does not use hashes for comments, actually uses double slashes. [INAUDIBLE] C# it's like that. That'll restore that, or rather rectify that issue if it does kick up a fuss. So when you paste this in, remember, again, with anything C#, we always have to terminate each statement that we make with the same kernel. And then we just want to import the namespace that stores the transaction manager, which I believe also comes from remote services.

Districts and more transaction is very quickly. Whenever you create something inside Revit, you've probably noticed there are certain features which have a little tick box. So if you're creating a floor, you will have a little tick box in Revit. And you have either a red x or a green tick to either accept any modification or any creation of a floor. Revit will check, perhaps, [INAUDIBLE] a valid profile. And then if it's valid, it will then create the object for you. And if it's not, it wouldn't allow you to create it.

That's actually creating what's known as a transaction behind the scenes for you. And that transaction just protects Revit and the Revit database from any invalid changes that might break your model. And as a developer, whenever you make any of the three following things, a new element, a modification to an element, or deletion of an element, you always have to declare those actions between the lines of your transaction.

So you have to open up a transaction, make all of your changes, and then close the transaction to submit that to the database. And then, it's either going to fail or it's going to work if you've written your code correctly. So the transaction is just a context required by Revit to enable you to make modifications to its database. That's all it's there for.

And again, a bit like this morning when I said there are some things which you really just don't have to concern yourself with, and I would say one of them is transactions. If you always remember to copy these lines of code into your node, and if you always remember that if you're making any of those three specific actions that I just mentioned, and those actions are declared between your transactions, then you've got nothing to worry about.

You can just focus on the problem and just not even worry about all these nuances and formalities of the Revit API. But that's what the transactions there for. So we're opening at the top and we're closing at the bottom. And everything which we're about to do now is going to be declared within that transaction.

So the first thing in which we want to do is we want to create a family type that matches the properties of one of the desks inside the desk arrangement object. So the desk object that is stored inside-- the desk arrangement in which you created with Radu, that stores width and length. And I think it's actually just those two properties that are specific.

Now, in the real world, when you're using Revit, if you want to declare any family type, like diligent Revit users do, they always duplicate the type, give it a brand new name, and then they go ahead and use that type throughout the rest of their project. It's no different assigned to the Revit API context either. As I said, what you do inside Revit normally is what you should also be doing within the KPI context as well.

So for that reason, we want to not modify an existing desk type with the width and length properties of the desk, and so there's is going to be an arrangement object. What we want to do is just create a brand new one with a name that we give it. And for that, I've already created a class for you. And I don't want you to write this. What I'd rather you do is open up the data set. And I'd like you to just literally drag and drop it into your solution. So if you just go to S3 zero touch. Go to the completed project, and you'll find a folder called family type. And I'd like you just to drag and drop that in.

We could spend time running this all out. But really, it's going to serve little purpose because it really just reinforces concepts which you've already been taught through this exercise. So just for expediency and so we can just focus on the egress checking as well, I'd like you to just drag and drop this in there.

But all this class-- or rather, this namespace contains a class, and all this class does is create a brand new family type for you with a name that you give it. So just do the following. That for which this family type, drag it, drop it onto zero touch nodes, and it will now magically appear inside your solution. And you've just got one new class called family type creator. And this, by the way, is a private class, and it's got a internal static method.

So the reason why I've declared it as private, and I've declared the method as internal, is for the following reasons. First of all, I do not want this to appear as a node inside the Dynamo library. So as a developer, you can actually make a decision as to what you want the end user to have access to. And that's what you would use these access modifiers for. So public would always display in the library. Private and internal will never display in the library. And private can only be seen within the type.

So for example, I'll show you exactly what this means. If we could just go back to desk creator. And what we're going to do is we're going to call the family type creator method to generate any family type. So for this, I just want you to do the following. Declare a family symbol. We'll just call this new desk type. Equal sign. And we're just going to say family type creator.

If it can't find the type, just hover over it and just accept the user statement it suggests. And when we do that operator, there's one method that's called desk. And it just takes a family symbol, the desk arrangement object, and then a name for our new type. And this will actually appear inside Revit after we've complete this. So it is serving a purpose beyond our node.

OK, so the first input then is the family type. Now, we actually are parsing this family type into our method. It's at the top here. So we just want to copy that. And then parsing to there. There was a problem though. There is a rapped element, and this method here is actually calling a Revit API method, which is why one of the input parameters for the method that I have declared is a family symbol. And the simplest way to do that within C# is just give it to operator, and then just use this internal element.

In theory, you could do this with Python. But Python has a number of other methods which can be used. Named [INAUDIBLE] use this morning, which was like unwrap element. You can use those methods in C#, but you'll find that the vast majority of zero touch node developers who will use elements coming from Dynamo almost always use the internal element just as a property, which is what I always use as well.

So internal element is literally returning the family type as an unwrapped element. There was one other catch. This is basically returning the type. I'm going to have to get technical again. I'm sorry, but I'm going to have to do it. It's returning the type as its base class. So what I mean by that, if you go to the Revit API, you [INAUDIBLE] on screen and find family symbol, which is what we're currently declaring.