Making the Leap from iLogic to Add-Ins—or Not?

JON BALGLEY: OK, so welcome to this class with a really long name. You got to see all this already. You got to see that already. So there's a lot of material to cover. So I'm just going to jump right into it. Agenda is a quick overview of iLogic. How many of you are at least basic-- have basic familiarity with iLogic? Yeah, pretty much everybody, OK, good.

Then I'm going to talk about this idea of class libraries. I know the headline was using iLogic rules or addins. But it said or not. This is the or not. Class libraries is a third option that's kind of in between. We'll talk about that. Then addins, and then we'll have a comparison of the different technologies.

OK, what's not on the agenda, of course, details about iLogic, how to program, that whole pile of mess there. You need to memorize it all. But I'm not going to tell you how do that today. And then, in general, I'm going to give you a kind of high level description of the various procedures. We're not going to go into step by step stuff. The main idea that I want to convey to you is why and when to choose one technology over another. There's plenty of resources out there that will-- once you know which one to pick-- that will help you get through it.

All right, so quick overview of iLogic rules-- so iLogic rules are basically VB.net code with some aspects hidden. So as I'm going through this slide, nod your head if you're with me. All right, some aspects hidden, like sub main. You can put that in, but you don't have to have it there. So it makes it easy for new users to adopt it. There's a built in editor with snippets that helps you get started.

It's got this built in compiler. So if it is VB.net code, something has to compile it and run it. But you don't have to pay attention to that. It handles all that behind the scenes. It's typically invoked automatically. You don't have to run the program. It takes care of running the program, because it's got parameter triggers or event triggers. Right, nod your head.

Easy to use wrappers, all kinds of things in the snippets-- you can still use the Inventor API directly from your rules. Right, you got that big pile there. And there are some minor extensions to VB. So for example, the way that you can refer to parameters, invent parameters as if there were local variables, that's not a built in part of VB. That's something iLogic does for you. Also, you may not know this-- I didn't know this at first, either-- was you can say, instead of just giving it numeric values, you can actually say 10 in or 10 cm. And it will interpret that as centimeters or inches. So that's also an extension to VB that iLogic provides.

And then in addition, there's two kinds of iLogic rules, internal rules and external rules. Right internal-- nod your heads, everybody. Right, internal rules live in the part or assembly files. External rules live in a separate file, right-- iLogic in 60 seconds.

And then forms-- forms are even easier to use. They're basically a simple pop up dialog box, easy drag and drop construction. They only support parameters, properties, and rules as buttons. So they're not infinitely flexible in terms of their UI, so simple and limited-- OK, forms in 30 seconds.

All right, just an example just to remind you, a simple form-- this is kind of the extent of what you can do with iLogic as configuration. I made this joke in my earlier class that it always seems funny to me how many people, how many customers make some kind of box where the parameters have to be length, width, and height. How many of you make something that could be considered a box? Yeah, a good chunk, half the class.

So anyway, this configuration-- some of them have lids. Some of them have T handles. Some of them have C handles. All the different dimensions are configurable. That's the kind of thing that you can do with pure iLogic. And we'll look at this. This was the example that we used in the intro lab that was kind of the last exercise of the intro lab on Tuesday and shows you kind of the limit of the beginning of-- sort of the high end of the beginning.

OK, so in summary, it's easy to use and integrated with Inventor. Integrated with Inventor, of course, is a key thing. We'll see the other technologies are not quite so integrated. Internal rules typically require using the copy design command. There's several copy design commands, but a copy design command, because you need to make copies of the files, typically. Nod your head if that makes sense. Or shake your head if it doesn't. OK, good.

External rules is where you get to choose the storage location. In some ways, that's an easier to manage thing, because the rule is just in one place and not copied in every part file everywhere. And in other ways, it's harder to use, just because it's outside the part file. And it takes a little while to get to it.

And then the last thing is events are another way to trigger rules that's kind of a built in thing. You just drag the rule over to the event and [POP] it's hooked up to the event. So very, very easy to use, very simple, that's kind of it. All right, so that was just kind of a review to give us a solid common understanding of where we're coming from with iLogic technology. And I think that that's mostly-- nod your head if that's mostly solid [INAUDIBLE]. OK, great.

So the next thing that we're going to look at is using iLogic in conjunction with a class library. And so this was, as I said, this was the 'or not'. This is a different-- this is another alternative to using just plain iLogic or jumping up to an addin.

OK so there's two major use cases. It's a very flexible technology. But it's easy to break it down into these two major use cases. So in one scenario, is you can use it for dialogues that are a little bit more complicated than what you can do with an iLogic form. So here I've got an image as the background. And I've got these text boxes in the right place. And they're with these dimensions. And everybody laugh at the lousy graphic design there.

[LAUGHTER]

OK, Yeah. So this is me just sketching it out in five minutes. And so you can-- the idea is, of course, to pick a nice looking one that goes beyond the very limited capabilities of iLogic forms. Now the main thing why I wanted you to laugh at this, besides the fact that it's horrible, is to see the blue and the orange. Throughout the session today-- by the way, is that-- it looks kind of yellow to me? It's orange on my computer. Anyway, blue and yellow-- the blue is general concepts that are applicable to the concept that I'm teaching. The orange is specific to the example that I'm using to represent it in this case.

So terrible graphic design, that's just an example in this case. Doing it for dialogues that are more complex than forms, that's the general concept. All right, so we'll see that all throughout. Pay attention to where it's orange and where it's blue. The orange stuff is unique to the example. The blue is the general concept.

OK, and then the second thing is when you want to write more complex code than you really are comfortable doing inside the rule editor, and you want to use that from your rules, but not write it in the rule editor. And we'll take a look at that, also.

So I'm going to get into a little-- this is where I'm going to get into some more detail. So what can a class library do? Well, one thing it can do is show a custom form. It's really easy to make forms in Visual Studio. There's different technologies for creating user interfaces. In this example, you'll see that I'm going to be using kind of the oldest, most primitive one, the simplest one, the one's that closest to iLogic forms. But there's no real limitation on that.

The second thing you can do is use the Inventor API. And you can-- by doing it in that context, you get a better debugging environment. Visual Studio is just great for larger, more complex code. And that's why it makes sense to keep that in a class library and keep your iLogic rules simpler. By moving that code into a class library and keeping the hard stuff there, you keep your rules nice and simple.

And then the last thing, of course, is that the whole technique is to allow it to be invoked from an iLogic rule. It's not a standalone thing. It's an adjunct to iLogic rule. So the iLogic rule is the driver, the caller. And the class library is a supporting role. It can be a huge supporting role with a little tiny driver. But it's always a supporting role.

So what is a class library? It's a DLL. If I say that, does that-- everybody nod your head, DLLs? Yeah, OK. It exposes public classes. So in Visual Basic, in iLogic, you've used classes. Even if you don't know it, you've used classes. That's what Visual Basic is all about, in a lot of ways. And so you're kind of extending that.

And then, of course, the classes have properties and methods. And that's how you consume them. That's how you consume the class libraries' functionality from your rules.

So to do-- so now I'm going to kind of get into the procedures of doing this. So since they're programs, you're going to jump up and become a programmer. How many of you are programmers? Yeah, how many of you have Visual Studio? Yeah, OK. So I probably don't need to cover everything here. But let me just say a few things about it.

So first of all, you need Visual Studio. I'm only going to give you the minimal introduction today. But again, there's plenty of resources for that. You have to choose a language at some point. Typically you will choose one of the managed languages, VB.net or C#. There's pros and cons for both. But let me just say that unless you already know a good reason to be using C++, you probably want to be using one of the two managed languages.

So if you know a good reason to do it, you can do class libraries in C++. But it's generally easier to use one of the managed languages. And unless you have a really good reason for using C++, you'll want to use one of the managed languages.

And then finally, the last thing I'm not going to talk about today but you will want to use is some kind of source control. Source control-- does everybody-- anybody want me to talk about source control? Everybody know what source control is, kind of? You want to know it? OK, so source control is a system that lets you manage the versions of your code files so that you can make a change, and check it in, and then keep track of that as a version, and then restore it back. There are a lot of different tools for this. A very popular one these days is Git, G-I-T, or GitHub. We're using that at Autodesk extensively. And it's the hot thing at the moment. But there's a lot of other tools, as well, that are also very good.

OK, so we're going to see how to use a class library to create a custom dialog, that ugly dialog that I showed there. The way we're going to consume it when it's all done is through a rule. So here I've got a rule configuration dialog. And you can see in here I'm consuming it by making a new instance, a new object of that class. I'm going to kind of double click into the details here. But the main thing that I want you to get off of this slide is that it's a rule. And it's invoking the class library somehow-- invoking a class from the class library somehow.

All right, so double clicking into that, here's the details here. So the first thing that-- now again, this is in the caller. Assuming that the class library is already built, this is the caller of it. This is your iLogic rule. We're in the Rule Editor here. So this is your iLogic rule using the class library, assuming that it's already been done, been finished.

So I'm going to make a new-- an object which is a new instance of this class. The big dialogue is the class. That object has some properties, d height, d width, d length, whatever. And these are the parameters from your file. They're in blue. All right, how many of you use-- this is the modern color. There's two kinds of color schemes now. This is the modern color scheme.

So these dark blue ones are all Inventor parameters. So I'm taking my Inventor parameters. And I'm assigning them to properties in the class object. I do all that. And then I call the show dialog method of that object. It has a show dialog method. And it's going to return a result. And if the result is blah blah blah blah blah, OK.

Then it's going to pull the value-- the properties-- pull the values out of the object properties and into the Inventor parameters. Right, pull the values out of the properties and into the Inventor parameters. And then, of course, any other rules that were triggered by those parameter changes will run in the normal way.

So it fits right into the iLogic schema, so to speak. Schema-- I don't know if that's really the right word-- the iLogic style. But it's consuming this external capability that we're going to implement now. So it's being invoked from iLogic, key thing.

All right, so how do we make one of these? Now we're going to have to dive into how we're making the class library. So we're in Visual Studio here. This is Visual Studio. And you started a new project. You're going to ask it to be a Windows project. You're going to say it's going to be a class library. So all of this is built into Visual Studio. You don't have to do anything special to say, make me a Windows class library. That's what Visual Studio does for a living.

Yeah, was that a joke?

[LAUGHTER]

All right, all right-- who laughed? Anyway laugh? Anybody need a brain to laugh? Brain, brain, brain? All right, that's too far. I can't throw it that far. All right, thanks for laughing.

OK so of course you needed to give it a name. I think I called it my-- I think I called it something else in the other slides. I did this a couple of times. But unlike me, you're going to want to add it to source control. You're going to have a source control system. And you're going to want to add it.

Once you've got a project, then you can add things to it. And so what we're going to add first, add here, is a form. And here I'm going to use the old style Windows form mechanism. Because it's very simple. And of course, you give it a name. You click on Add. And then it lets you design the form in the same way like the iLogic Form Editor does. You can drag and drop controls from a list onto the layout. And then you can control the properties of each control. And then if you double click on the control, then you get to edit the code that goes along with that control.

So it's a very simple-- this WinForms is a very simple old style technique. It's got limitations. But you can get right into it. And all of sudden, you'll get a lot more capabilities than what iLogic forms provide. So in particular, it lets you underlay an image. So I'm underlaying an image and placing these controls where I want on top of the image. That's what I'm taking advantage of here.

OK, then within Visual Studio, you can edit the code for all those controls and the whole class that controls the form. So I've got this class that controls the form. It's called Big Dialogue. And here I've added a handful of properties. And we saw them in the rule, right? So this is where they're defined. So you can use Visual Basic. Here we're using pure Visual Basic, no iLogic stuff here. Define some properties. And then this is where the iLogic rule will push and pull values in.

And then there are two important events for a dialogue. The first one is the load event. And that happens when the window is first shown. So at that point, I'm going to take the values from the properties and push them into the controls. So the text controls are the things that will allow you to type into them. And there are the handle types. And there's the checkbox. And so I'm going to take the property values from the class and push them into individual controls, which are themselves. objects with properties. And so that's what I'm changing the text property of that object.

So that's when the window is first shown. And then this event, the click method on the OK button, is, of course, invoked when you click. So it's going to go in the other direction. It's going to take the string of text that's in the text control, try to turn that into a number, and assign that to the various properties of the overarching class. And if any of those fail, then it's going to complain about it. So it's very simplistic. This is a simplistic example-- and then finally hide the window.

OK, so what we're doing is we're pushing the values from the properties into the controls at the beginning. And at the end, taking the values out of the controls and into the properties, all within the class object so far. It hasn't gone back to iLogic yet. But that's what we saw at the beginning, right, was iLogic pushing and pulling into the properties of the object.

So the last little piece that's convenient and something that, again, I didn't know right away, I had to learn after a while, is that the-- come back-- is that the-- come on-- is that the Forms tab is itself a form. How many of you knew that? The forms tab is a form. And if you right click on the blank area here, then you've got this Edit command. And then you can drag and drop things onto the Form tab itself.

So you can drag this rule onto the layout of the Form tab. And then when you finish that, then you get another button on the form tab. So it looks like it's a form, a regular iLogic form. And it just shows up in the Form tab. So it's just a very nice way of doing it. And then when you click on that, then you're going to get that nice-- or maybe not quite so nice-- dialogue with the arrows, and the overlays, and yeah.

So it's a step beyond-- so using a class library for a more complex form is a step beyond using iLogic forms. Tada, that's what it looks like. It's ugly, what can I say?

All right, the second kind of major way of using class library is using the Inventor API more deeply. So here's the problem set that we're going to try to solve with this. This came up on some forum recently. I think it might have been the Inventor beta forum-- where we want to compute a bounding box that's not aligned with the XYZ coordinates, XYZ axes, but rather is aligned with some other set of axes. So it's a crooked part. But we want to have that tight bounding box around it.

So the way-- what we want the user to do is to pick one linear edge and then create the work planes at the far ends of that, and then find the orthogonal directions, which is a trick in itself, and put work planes in that direction. And then the inside is the bounding box. Seem reasonable? Yeah? Kind of a cool thing, don't you think? Yeah.

So it turns out that the Inventor API has a Far Point command. Yeah, it's right over-- right over there.

[LAUGHTER]

And we're going to make a class and a method that will use that to generate the work planes. So there's a way to make a work plane at a given point. We're going to do this-- the edge selection, we're going to do from the rule. We're not going to try to do that from the class library. The class libraries, we're going to keep the interaction in the rule, in this case. And because it's pretty simple, all we want to do is preselect an edge and then have it do its work from there, and then call the method from the rule.

OK so again, this is what the rule will look like when the class library is completed. This is how we're going to consume it when it's done. So we're going to add-- so again, this is the Rule Editor. We're going to add a reference to the class library. And all of this is unique to our particular example, of course, where we're just checking the preselected collection of entities, checking to see that we actually have one, checking to see that it's a linear edge, and then getting the direction out of it, blah, blah, blah, blah. This is that part of the API over there.

And then we're going to make an instance of my new class. We're going to pass in this application. How many of you know-- do you know what this application is, yeah? Nod, nod, yeah. And then we're going to call this entry point method. So this is the thing that's going to do the work.

OK, now over to Visual Studio. We're in Visual Studio. We can use the same project. One class library project can have multiple classes in it. And then you can pick and choose based on which one you refer to which one it does. So you can put a lot of stuff into one class library, if you want. Or you can have individual class libraries with fewer classes in it.

So-- come on. So we're going to say Add a New Item. It's going to be a class. We'll give it a name. Here's where I say it's Geom Tool. And then here we are in Visual Studio. And so we're making a class. It's called Geom Tool. It's got-- its declared to be public. There's always-- these member variables are unique to this example. But there's always going to be some member variables. And it's very common for one of them to be the application.

And so by having this in here, then I can get at all the properties of the application object from any method in my class. There's a constructor. Let's look at that in a second. There's the entry point. We'll look at that in a second. And then there's a bunch of helper methods, as well. And so let's take a look at those. So the constructor-- here's where we write a little bit of code that says make one of these objects. And so this here says, what do I have to supply to do it? So here's where I'm providing the other side of that that we saw that says that I must receive an application object in order to be constructed.

And then I hold onto it in that member variable. And oh, by the way, I'm going to get hold of the transient geometry object, as well. Transient geometry, who's familiar with that? Every familiar-- who's familiar with that? Not familiar with that? Not familiar? Yeah, OK. Transient geometry gives you access to temporary raw abstract geometry, like points, and vectors, and matrices, and planes, just in a pure mathematical sense. There's no representation in the part or assembly file, just in a mathematical way. That's why it's called transient. Yeah-- and a button--

All right, and so this is the main entry point method. And it's going to call the helper functions. So in this case, I'm going to receive the part document. I'm going to receive the vector. I'm going to get the surface bodies out, so more API stuff, right? I'm going to find a perpendicular vector. Anybody know how to do that off the top of their head? You have a vector going in one direction. You've got an infinite number of vectors perpendicular to that. Anybody know how to do that? It's tricky, tricky. I'll show you that in a second.

But once you've got that, then you can use the cross product to get the perpendicular vector to those two. And then I've got three orthogonal vectors. And then what I can do is I can-- assuming this, I've got a helper function that will take a primary direction and two secondary-- a secondary and a tertiary direction and create work planes at the extent in one direction, the extent in the other direction, and create a pair of work planes. But if I call it three times, then I'll get all six of them. So once I've got the three orthogonal vectors, then I can call it three times to get the three pairs. And that will take care of it for me.

So this is the helper method that creates one pair. You know what, I don't really want to go into this all that much. This is all yellow here, except for the fact that it's all about the API. So in this case, the key API thing is this get far most point. It wants a surface body. It needs a unit director, blah, blah, blah, blah, blah, lots, and lots, and lots of API stuff. And then eventually, it's going to call work planes dot add fixed, duh de duh de duh de duh-- oh yeah, create some work points, also, duh de duh de duh de duh-- all right, so typical kind of thing that a class library used for this purpose is going to have all kinds of calls into the API. Personally, I find that there's a lot of this kind of-- you know, first you need a-- you get a regular vector. And then you need a unit vector. And then you want to do something else to it. So you need to convert it back to a regular vector, so all kinds of API magic that is unique to this particular example.

This is the helper method. I've made it public. But in retrospect, I think maybe it would have been better if it was private so that it wasn't exposed. And this is how you can compute a perpendicular vector. Well heck, I didn't know how compute a-- how to compute the arbitrary perpendicular vector. So I searched for it on the web. And what do you know, I found 15 hits for how to compute a perpendicular vector.

This one happened to be in Python, originally. But I could read the-- I don't know Python. But I could read it pretty quickly. And I instantly converted it to VB.net. And I was on my way.

So key thing is use the web. Somebody else has already done it. No question, and you're just kind of reassembling it into some other-- reassembling those components into a different thing. I don't think anybody else has done this oriented bounding box thing. Because there's this whole discussion going on right now about how to do it. But people have been doing all this stuff for ages, right? All right, so it works, if you call it. I mean, I could show you. But that's what it looks like.

So what is it about that? That doesn't seem all that satisfying to me. It seems kind of clunky. What did it do? You guys saw that it was doing the add-- it was adding work planes and work points, right? What is that going to do to the model tree?

AUDIENCE: [INAUDIBLE]

JON BALGLEY: Yeah, all of a sudden, it's going to have six work planes, and six work points. And they're going to have kind of funny names, or something. And so it's kind of clunky. But on the other hand, it was relatively easy to write, and especially easy to invoke from the rule. The rule had a bunch of stuff about dealing with the pre-selection. But then it just had two lines to make all the-- make the bounding box.

So-- oh yeah, so a couple of key details about how you do this in Visual Studio, or how you do this-- first of all is when you create-- when you-- you're going to build this as a DLL. And so the DLL has to go in a certain place. If you just put it in this location, Inventor bin iLogic add, then iLogic will find it. And so that's the easiest way to do it. And you just put it there. And you're golden.

It's really nice to be able to do that all the time so that every time you make a change to your code and you say build, it also will put it in that crazy location so that it's there when you need it. So if you go through this process, you go to the Properties of the project, go to the Compile tab, click on the Edit Post Build button, then you get to have a sequence of commands that it will execute after it's finished building. And so at that point you can call this X Copy command. And it will copy it to that location. So basically, every time you build, it will install it for you.

Well, it turns out that that location is almost certainly only accessible by admin users. So hopefully you have admin access. If you create a shortcut to Visual Studio, you can select Properties. And there's an option to say Run as Administrator. And so if you do that, and you-- so run Visual Studio from the shortcut. Then it's got Admin rights at that point. And so that X Copy can copy into that folder.

And then the last key detail is in order to debug it-- yeah, Tom.

AUDIENCE: So, I'm not sure if you know this, Jon, or not, but in that previous slide, that's just the Inventor default location for DLLs. There's a way to configure that within the application itself. You can define that any path at all. So that could be local. That could be somewhere out on the network. You could have then shared them if you want to. But that's just the general path.

JON BALGLEY: OK.

[PHONE RINGING]

That's not me, is it? OK. That's my ring tone, so-- Yeah, OK. Thanks, Tom. Yeah, I'm-- feel free to-- if anybody knows something like this, feel free to chime in. I'm trying to keep it on the simple level, primary obvious things first. But yeah, thanks for that contribution.

OK, going forward here-- Admin shortcut. Yeah, startup app-- so this being Visual Studio, and this being VB.net code, of course, you're going to want to debug this code as you're working on it. So the way that you have to run something-- you have to run something to debug the code. Since this is a DLL, what are you going to run? Well, of course, you want to run Inventor, right?

So within the properties of the project, there's the Start Action property-- property? I don't know, yeah, option-- and what we're going to do is we're going to start this particular executable and debug that. So even though it's Inventor, it's enormous, the thing that we're actually running when we want to test it is Inventor. So you have to give Inventor as the startup program in order to debug your little DLL-- key thing.

So then once you've got all that hooked up, if you just are editing your code, saying, OK, yeah, I think I'm in a good point, if you just click F5 at that point, then it will build your code. If it's successful, it copies it to the right location, which you can configure it to be any location that you want, and run Inventor. And then if you have any breakpoints set, it will hit your breakpoints and duh de duh de duh. So it's very, very nice. You just kind of type in your code, hit F5. You're up and running.

Time check-- yeah, OK. All right, so hitting breakpoints, of course, this is a typical Visual Studio thing. You just click on the left column here. Where do you want us to stop-- when it hits that piece-- hits that line of code, it stops. You can inspect what's going on there. You can use the dynamic pseudo property there to see the contents of your objects-- very nice. It's the-- Visual Studio is great. Everybody nod your head if you think Visual Studio is great.

The other thing that's really interesting about hitting a break point in this context is that you have access to your rules code, as well. So your rule is on the call stack at this point. And your code is there. If you look at the call stack down here-- oh, I got the arrow not quite-- the arrow moved a little bit. You'll see this rule as an item on the stack. And so you can step through that code, as well. I think I have it here.

So here we are. We're in Visual Studio. And we're looking at this code here. And this is my rule code. So now you can step through your rule code, as well. You can set additional breakpoints here, if you want. You can see the values of these various local variables. So if you've got Visual Studio-- that's a big if, because it's expensive-- then you can debug through your rules.

AUDIENCE: [INAUDIBLE]

JON BALGLEY: I was talking with somebody from another-- one of the higher-ups at Autodesk. And he and I were agreeing on the phrase, undocumented feature.

[LAUGHTER]

Yeah, the iLogic team went to some effort. I get to call the-- anyway, the iLogic team went to some effort in 2019 to make the code that you see here be quite clean and to put it in a place where Visual Studio can find it easily so that this works. But we're not really quite ready to say to the broader Inventor audience you have to buy Visual Studio if you want to debug your iLogic rules. But if you're already committed to Visual Studio and you already have it, oh, then great. Take advantage of that.

OK, a couple of little things here. So you'll see this end sub and end class that iLogic puts in there automatically. So it's 99% of the code that you see in here is the same as your rule code. But there's like 1% difference dealing with the parameters as local variables. You'll see things like that. Dealing with the units, you'll see how it does that. So that's easy. You don't have to worry about that.

What you do need to be concerned about is that this is read only. It's generated code. It gets thrown away. Only your real iLogic rule code is kept. And so this is just temporary stuff. So you're welcome to look at it, set breakpoints there. But you can't-- save-- you can't make changes there and save it. You can't edit that code. You have to go back to the rule and edit the rule.

OK, and if you want to force it to break without having to go through a break point in your DLL, you can put in this word, literally the word break. And if you're running with the debugger attached to Inventor, it will break at that point-- kind of a nice undocumented feature-- don't-- secret, secret, secret.

OK, so class libraries, so pretty simple to use, very powerful. Because you've got the full power of the API. You've got the full power of Visual Studio. There's very little special plumbing. All you have to do is plop that DLL into one of the standard locations. And then you're on your way. Invoke it from your rules. And then you're good. Take advantage of that, especially source control. And then there's two different kind of usages for how people typically use it.

And this is, of course, huge. How do you-- doing anything to the Inventor model. OK, everybody stand up for one second. Stretch, stretch, stretch. Yeah, yeah, yeah-- brains, who needs a brain? Anybody need a brain? Brain--

[LAUGHTER]

--brain, brain--

[PASSING THINGS OUT]

--need a brain, yeah. Who needs a brain? Yeah, Michael.

AUDIENCE: Thank you. Buy those by the gross, or what?

JON BALGLEY: Yeah, you can buy them by the gross, yeah, yeah, yeah. Yeah, Dustin, anybody else need a brain? I don't want to bring any of these home. My wife would not be happy with a bag full of brains. I'm sorry-- all right, last one. All right, thank you, everybody. Now I can go home happy.

AUDIENCE: [INAUDIBLE]

JON BALGLEY: Code, no. So the real downside of this is that it requires real Visual Studio. Visual Studio Code does not work. Visual Studio Community will work, except that it's most-- for most Inventor users, you probably won't-- in my not really lawyer opinion-- you don't meet the criteria for using the free version, the community free version. You'll have to ask your lawyers, of course.

AUDIENCE: What about express?

JON BALGLEY: No, well, Express is dead.

AUDIENCE: Express doesn't exist anymore. [INAUDIBLE]

JON BALGLEY: Yeah.

AUDIENCE: 2017 is the last version.

JON BALGLEY: Say it again?

AUDIENCE: Express 2017 does exist.

JON BALGLEY: Oh, does it?

AUDIENCE: So if you took [? Brian Egan's ?] class this morning, he actually provided a link to the download of 2017 Express in whatever class that was.

JON BALGLEY: So then I don't know. Maybe it does work in Express. The problem with Code was that it doesn't support VB.net. I mean, it will display it for you. But it doesn't debug or anything.

So next-- so that was the intermediate choice. The higher end choice is an addin. So what's an addin? It's a software package, a DLL that runs inside Inventor and adds additional functionality. Oh wait, wasn't that what the class library did? Well, yeah, kind of, except that this is really kind of intended to be bigger. This is intended to provide a package of functionality.

A class library is really intended to be kind of smaller. The addin is really intended to be bigger. There really is a huge overlap in that description there. But just kind of keep that in mind. Yeah, the addin has to follow certain protocols. We'll look at that-- pretty easy, and big. You might only ever write one addin. You might say, oh, this is my company's special functionality. And every time you want more functionality, you just add it to the one addin, maybe. So what can it do? The main thing that's interesting about an addin versus a class library is that it can really extend the Inventor UI, something way beyond what iLogic rules can do. Because rules run in this kind of constrained context that iLogic sets up for them as opposed to an addin, which is totally free to do whatever the heck it wants. And the typical thing that it wants to do is add new commands to the ribbon, add new ribbons, add more content to the files themselves that's kind of in a special way, manage the content of the files. And then the entire API, of course, is available.

The API exists to support addins. Addins are the reason why the API exists. And all these other ways of using the API, they were kind of afterthoughts. So the addins are expected to use the API extensively.

All right, so what we're going to do is take a look at this kind of clunky oriented bounding box example and say, hey, you know, that was kind of clunky. Wouldn't it be nice if we had a little panel that would allow you to, at any time, pick a new linear edge and show you the lengths, the length, width, and height of the bounding box, and the volume, by the way. And oh, by the way, maybe make the work features be visible or not on and off, right? So this has gone beyond that simple dumb rule that just did it to be a real piece of functionality-- still lousy graphic design. That's just kind of simplistic.

But it's a chunk of functionality, more than what you want to do from a simple rule. So that's where-- and oh, by the way, you can dock it on the side here, as a browser tab. Kind of cool, right? It's a thing.

OK, so very similar to class libraries, you need Visual Studio. You need to pick your language. Again, if you don't have a good reason for using C++, you'll want to use one of the managed options. You'll want to use the Inventor SDK. That's a secondary install. The Inventor installation puts another installer in this location. And then you can just double click on that to install it.

And it does two things. One is that it will add an addin project type to Visual Studio. That's really the key thing that you need. The second thing is that it installs this. And so you can get at that there. So that's kind of the two big things that it does. The first thing is really important. The second thing is kind of fluff.

So once you've installed the SDK, then when you go to start a new project in Visual Studio, you get an option which is create an addin. And so just by selecting that addin, it's going to create all the necessary components-- files-- in your project that are needed to be a genuine addin. So right out of the box, as soon as you say, create an addin project, it's a runable, buildable addin.

So it does a couple of things for you. There's two major files that it creates for you. One is the .addin file, which is a simple XML file, textual XML file, that contains a bunch of stuff that it uses. There's documentation on a lot of these things. A key thing that you might want to modify upfront is the name of the addin. It creates a GUID, globally unique identifier to identify that addin. So that's going to be your addin's identifier that you can use in other contexts. But it creates it automatically for you.

And then the second file that it creates that's important is this addin server file. And that's this next one here. And so here we are. This is the addin server file. It's creating a class-- where am I? Where did it go-- class using this name. So this was part of the protocol that the addin DLL has to follow. So by using the project template, it builds all that stuff for you. So it's going to handle the plumbing for you.

It will have-- there's two key methods that we'll talk about quickly. The activate method, that method is invoked when the addin is loaded. So it can do any kind of initialization. And then the second method, we'll talk about that in a second-- yeah, automatic GUID, good.

You'll see when you open the file that there is a ton of commented out code. That's just the example code. If you uncomment it out and you set it up to install the DLL in the right place and-- again, this is the same kind of thing-- and you set up Inventor as the start up project, then when you just build it and run it, then it will automatically add a thing to the ribbon, create one button on the ribbon, and all the ribbon does is pop up a little thing that says the button was clicked.