
We want a selection filter which simply ignores certain types of colors.
Here is the ‘simple’ result I came up with:

Any AutoCAD programmer knows that things which an algorithm may take a million years and infinite computational power to do can sometimes be easily done by a human being instantly. In the same way it is sometimes much easier to give a human being the ability to choose: then you can get an optimum result without complex algorithms.
This post is a code snipped of how you can utilise the CTRL + SHIFT + Mouse Wheel (up/down) mechanisms in order to produce different desired results when operating a custom jig.
Here is the code:
So when the appropriate user input happens, then the jig can respond accordingly. Yes it’s true – the OOP purists will say: “you’re passing a concrete type in there” – I can always change it later if I want.
This utilises WPF to compare panels, isolate changes and make better decisions.
See below for a demonstration:
WPF – Eliminating Errors using Cross Checking from Tek1 on Vimeo.
When you first get into .net API programming – for AutoCAD plugins, you learn this cardinal rule: make sure the three AutoCAD dlls you refer to have copy local set to false.
Why exactly is this the case? I couldn’t find a better answer than the one offered by Fenton Webb. Here it is in full:
Take a second to look at the AcMgd.dll and AcDbMgd.dll in this folder…. Do you notice that they are much smaller than the ones in the AutoCAD installation folder? There is a big reason for this which is that since the 2010 release of the ObjectARX SDK, we have “liposuctioned” the managed reference DLL’s. I say “liposuctioned” because we literally sucked out the body of the code from each function in the assembly DLL. What we did to create these DLL’s was to actually ILDASM (MSIL disassemble) the original DLL’s, strip all the body code from them and then reassembled them using ILASM (MSIL assembler). OK, now why on earth would we do that, right? Let me explain: the WPF UI designer (and indeed the WinForms designer) in Visual Studio is pretty cool in that it does a great job of showing the design of the UI on screen obviously. The problem is that the designer does like a half-hearted parse of the code behind that controls the UI in order to work out things like how it’s displayed for instance, which when we reference the external AutoCAD managed DLL’s can cause unresolved dependency errors and thus stop the VS Designer from working properly. These dependency errors are caused by the fact that the ac*mgd.dll’s depend on acad.exe which of course the VS Designer finds impossible to load in order to resolve the dependencies. By using the “liposuctioned” assemblies in your project, all of the object definitions are in place to resolve designer parsing issues. You’ll be glad to hear that it still compiles, and loads too! Just as long as you keep the Reference property “Copy Local” set to false for each DLL.
(Taken from Fenton’s WPF AutoDesk University course notes).
#Tekla API #Autocad API #DOT NET
AcCoreConsole is AutoDesk’s brand new toy. It is basically a command line version of AutoCAD. It has no “User Interface”. That means that if you are a user, there are no menus to click on. No buttons. Nothing. You have to do everything via text. Via command line, like it was in the very beginning.
You cannot see lines.
What is the benefit of this you ask? Well it allows for super fast batch processing.
Please watch my screencast for a very brief introduction to this new technology. I will provide another video of the batch processing power of this babey.
https://knowledge.autodesk.com/community/screencast/d6ef5929-4208-443d-8b53-eca0c637328a
I hope you learn something.
Ben