AutoCAD .NET -> Pouring quick set epoxy in your keyboard if it could

[Anonymous]

Am I the only one that is finding customizing AutoCAD using .NET to be a huge pain?  Is the effort required to get AutoCAD to do what you want it to justified? I say NO!

I started off programming AutoCAD by experimenting and taking in all I could at AU virtual a couple of years ago.  I remember at the time learning from these classes and practicing what they taught as if it was a religion.  From the start I saw posts by Tony T. and others that extolled the Object ARX documentation and pressuring aspiring .NET programmers to study and understand the deep dark details of how AutoCAD works.  At the time with my limited programming experience I thought that this was how the programming world works.  I remember one AU Virtual class where the presenter was showing how to put the transaction manager code into a snippet so it is easy to insert whenever you need it.

I wrote code, it ended up a huge spaghetti mess and then I took a step away from AutoCAD themed coding to learn more about coding design and architecture instead.  Now after learning how coding now works in the real world today, the AutoCAD .NET API and the Autodesk documention is HORRIBLE!!

I have been writing code using many frameworks and technologies and it takes 10X longer to accomplish something working with AutoCAD vs trying to do anything else.  Even getting a LOB app going using PRISM with MEF, Entity Framework, Generic Repository, Enterprise framework for logging and validation, and Microsoft Sync for occasionally connected applications (and some ASP .NET services as well for good measure) is VASTLY easier to accomplish knowing nothing then it is to build a add-on for AutoCAD that say opens drawings, plops in blocks from files, saves and closes said file, and repeat.

The biggest problem is that the .NET API drags all the ugly from AutoCAD's core right up front and center, and THIS IS WRONG.  I do not care how the plumbing was routed, how the electrical was put in or how many litres of water goes down the drain when the toilet is flushed.  If you were around a few years ago, Tony T was replying to every question and lambasting everyone to learn more about the plumbing of AutoCAD (ie study in depth the Object ARX documentation).  The posts seemed to take on a tone of "You &^$*&^$ .NET programmers, it is not that easy"

IT SHOULD BE!  If you look at the progress made over the last ten years and learn about proper coding practices and architecture you will see a huge effort has been made to improve software development.  I have read many an article about a coding topic where the author states that 10 years ago he himself was writing horrible spaghetti code, not intentionally (he did not know better), and then presents a topic that makes an effort at reducing the problem. 

If you want to understand how to make better code look up SOLID design principles and Group of Four design patterns.  (Of which I am sure none of the AutoCAD .NET API even tries to hint at following)

In the end it becomes clear that separation of concerns is important.  If I want to insert a block into a drawing it SHOULD be a straight-forward practice.  I should not have to work with the transaction plumbing, or the document lock electrical work. 

There should be a contract between AutoCAD and my program (interfaces, facades, etc (see design patterns)) where I can write AutoCAD.Insert("Blockname.dwg", options) and the professionals at Autodesk have all the plumbing and wiring done correctly behind the scenes. 

Why does every programmer need to have intimate knowledge about how AutoCAD works and every programmer repeat thousands of times the transaction code? Does ANYONE ask this question?

All material on .NET programming with AutoCAD should come with a disclaimer (I think Kean meantioned this in a post, and it may have been in ONE AU notes document) that states proper design practice should be implemented and how they show to do things is not what you would want to do in practice.

I have re-written my code and all the AutoCAD related code is placed neatly in its own corner away from my algorithms.  It is coded in such a way that I could rip it out and use paint as long as I implement the Paint.Insert to replace the AutoCAD.Insert as exemplified above.  I have created a library that suits my needs so it is now all simple calls to do things, and I do not need to worry about tables and dictionaries and definitions and transactions and document locks when all I am trying to do is place a block and update an attribute.

The transaction manager code appears ONCE in my code, yes, only one time.  Which is mind boggling if you read any AU virtual material, since I am sure each class has several if not tens or hundreds of transaction manager clips spread throughout.  This would be fine if there was a note, or a hint, or anything that says this is to learn how it works, but do not make it this way.  In fact a AU or AU virtual class should be avaialable that shows how you should be structuring your code and what efforts you should be making.

I am ranting because I am once again trying to achieve something with AutoCAD, and once again it is proving to be a huge pain compared to any other programming.

I basically started trying to make applications with AutoCAD, and my programming experience before this was small apps where architecture did not matter as much due to the small size.  I fought with the API around every corner to do every little thing since you need to know so much about how the original programmers made things.  I was BLOWN AWAY when I got into frameworks (Fluent Entity Framework, PRISM, MEF etc) and saw HOW EASY it was to do things that really are very complex when compared to inserting a block and updating attributes (which ironically AutoCAD .NET makes as hard as possible)

If you are going to work with AutoCAD .NET programming you should figure out what you want to do and abstract all the functionality away properly so you can focus on getting things done rather than mucking around with ancient coding paradigms.

Of course this is my own personal opinion based on my journey over the last few years of programming.  Does anyone else see any of this or am I just crazy from staring at too many drawings and too much code?  I am surprised (maybe I did not look hard enough) that the above has not been brought up.  Is it really just me or are there some code smells (look it up if you have not heard this) coming from this API?

[dgorsman]

Up until the past few years, there was NO dotNET for AutoCAD, then a limited abilitiy, and it's still expanding.  Thats a lot in a short time.  Keep in mind there is likely still a lot of legacy code going on behind the scenes where rewriting to suit somebodies idea of what the API *should* be would break existing code and prevent implementation of planned features down the road.  Breaking the customers customizations (and, to a certain extent, third-party vendor programs) isn't a good thing to be doing.

Yeah, it would be nice if everything was simple, easy, click-click done.  But the inverse is true: simpler means fewer options, fewer ways of getting it done.  But hey, there's a plus side: like you did, you can create your own simplified interface!  Of course if they provided *only* that, I guarantee there would be complaining that it doesn't let you do this, or that, or the other.  While you might not care about Dictionaries and XRecords they are the heart of several of my routines (but those have nothing to do with a simple block insertion, so there is something else going on there...).

As for the AU materials, demonstration/teaching materials will have many transactions simply because they need a small encapsulated chunk to show a specific topic.  They aren't meant as a drag'n'drop toolbox - thats up to the individual users.  After all "Prior planning prevents p__ poor performance" hold very true the more complex software gets.

[adam]

Hi TonOfSteel,

I can sympathise with the comments regarding Transactions and Locks. There seems to be conflicting advice about when and where to use these.

As you say, all the examples are tiny so it would be great to see a higher level example that fleshes these issues out. We too have written some high level code to manage all of this – seems a waste of time that we are all writing the same thing.

However, we work on AutoCAD, Microstation and ArcGIS. The Autodesk API is BY FAR the best API of the 3. Chalk and cheese with regard to ease of use, documentation and general knowledge availability. Now it is no excuse that Autodesk’s should be sloppy in some areas just because others are even worse but I invite you to spend a few weeks with ESRI’s COM abomination and see how much hair, nails and sanity you have left!

Adam

[Alfred.NESWADBA]

Hi,

Just my 2c, because I think there are things mentioned with only seeing them from just one side

>> From the start I saw posts by Tony T. [...]

>> and pressuring aspiring .NET programmers to study

>> and understand the deep dark details of how AutoCAD works.

If your goal is to build great/best cars, what people do you think will be able to built the best car? The ones only knowing how to drive a car or the ones knowing how a motor is built up, how arodynamic works, with a lot of mechanical knowledge?

It's clear (for me) the more and deeper knowledge you have the better and more efficient results you'll be able to get.

And that is the same to AutoCAD (dgorsman already mentioned), the less options you have in the api, the more simple it seems to be. But the less options you can use the api will not be that powerful. If you don't want it you can either chose to only use the COM-API (therefor you don't need transactions, but you also loose speed and flexibility).

>> [...] posts by Tony T. [...]

I see TonyT as one of the greatest guys knowing the most internals from AutoCAD .... and having the knowledge he is able to write code/to customize AutoCAD in a way most of the others would first say "you can't do that with AutoCAD".

Yes, some wording TonyT has used (to others), could be done in a more friendly mode. But the technical part of him is great, I have learned a lot from him. (thanks if you are reading again here 😉 )

>> I should not have to work with the transaction plumbing, or the document lock electrical work.

Reading your complete post and seeing especially the above sentence you want Autodesk to give up the TransAction-handling as you find it useless. Pardon for my words, but you are then saying that all people using databases in a performant way (not just MS-Access) are silly because for them TransActions are the most necessary method to have high performance, to have undo-ability, to have plausibility checks concentrated. If you don't know what TransActions are for, don't use them (you don't need them, you can also do .UpgradeOpen and .DowngradeOpen and .Open and .Close instead) but don't rant against TransActions because they are really needed.

>> The biggest problem is that the .NET API drags all the ugly from AutoCAD's core right up front

>> and center, and THIS IS WRONG.  I do not care how the plumbing was routed,

>> how the electrical was put in [...]

And the reason you don't want to care about these things makes you automatically thinking that others ones also don't want to step into these details and don't want to make some modifications to these internals? Wrong thought, AutoCAD gives the ability (for those who need it and know how to use it), if you don't need it it's not a reason for Autodesk to remove the functionality.

Sorry, that sounds like you never use Arcs, so Autodesk should remove Arcs from the functionality and also from the menu's because one button more is one complexity more.

So back to top and to this statement:

>> Am I the only one that is finding customizing AutoCAD using .NET to be a huge pain?

I can't speak for all others, just for me: I don't find the .NET-API as pain, really not. Just wishes to get more access to more details 😉 but it's growing and so the hope for more details exists. 🙂

SCNR, - alfred -

[Anonymous]

I do not totally disagree with the arguments that have come up, and in fact if I was to reply to my post a couple of years ago I am sure that I would have had the same theme to what has been posted.  I posted the original message because of what I have learned, and it comes not from what I think it should be, but from many different sources criticizing the way that I myself was programming.

---

I see TonyT as one of the greatest guys knowing the most internals from AutoCAD .... And having the knowledge he is able to write code/to customize AutoCAD in a way most of the others would first say "you can't do that with AutoCAD".

Yes, some wording TonyT has used (to others), could be done in a more friendly mode. But the technical part of him is great, I have learned a lot from him. (thanks if you are reading again here )

 

---

I agree with this, and I guess I did not mention it in the original post but I as well have learned much from him, and have solved problems based on his posts.  I greatly appreciate his contribution to AutoCAD .NET forums. 

---

If your goal is to build great/best cars, what people do you think will be able to built the best car? The ones only knowing how to drive a car or the ones knowing how a motor is built up, how aerodynamic works, with a lot of mechanical knowledge?

It's clear (for me) the more and deeper knowledge you have the better and more efficient results you'll be able to get.

---

 When you are driving a car you are not concerned about certain things.  There is a separation of concerns since if you had to worry about confirming for the on board computer every time the crankshaft rotates one revolution from the driver seat while you are in the middle of driving, every time you drive this is a poor design of a car.  If this is done behind a API, that the driver can override and choose to do this if he/she wants, this is better and more flexible and allows you to apply your superior knowledge in any case it is warranted.  I am talking about programming practices and principles as well as software architecture and structure, not about the technical details that make up the API. 

---

Yeah, it would be nice if everything was simple, easy, click-click done.  But the inverse is true: simpler means fewer options, fewer ways of getting it done.  But hey, there's a plus side: like you did, you can create your own simplified interface!  Of course if they provided *only* that, I guarantee there would be complaining that it doesn't let you do this, or that, or the other.  While you might not care about Dictionaries and XRecords they are the heart of several of my routines (but those have nothing to do with a simple block insertion, so there is something else going on there...).

---

I only reference a couple of the points but they all seem to point in the same general direction: Simplicity means less functionality and control.  This is hardly the case at all.

I am going to try and outline where I am coming from, based not on my imagined idea of what the API should be, but what someone that has much more experience and knowledge than me has said when they looked at my code.  By the way the arguments are coming in it seems that people are not familiar with SOLID design principles and GOF design patterns as well as other patterns and practices of modern object oriented programming.  And I mean not just reading them, but becoming familiar with refactoring your code and applying them as well. These concepts were not just dreamed up as some arbitrary thing to do, in practice they really do make coding and maintenance much much better, and code development much much quicker.  I at one time did not necessarily agree with all of it, but I am sold now.

The transaction manager code *needs* to be called when required.  It does not matter arguing about it being there or not, or whether interacting with it or not is going to affect your code.  The way the examples and documentation are given it shows transaction manager code all over the place.  And this is a requirement for coding with the raw API, there is no other way to do it if you want to use the transaction manager.  This is fine, I like the transaction manager and I can sleep better at night knowing that I have control and it has not been hidden from me.

Now you go off and create some application and notice that there is transaction manager code sprinkled all over the place.  This violates DRY (Don't Repeat Yourself), SoC (Separation of Concerns) and SRP (Single Responsibility Principle) since obviously there is repetition and now instead of just achieving what you are trying to do with the entity, every object is concerning themselves with the details of a transaction.

If you refactor the code so that the transaction manager is only in one place and structure your code using the proper design patterns you end up with code that is much easier to maintain and so much easier to extend or add features since now the transaction manager is taken care of for 99% of the use cases that I would need. 

Using MEF with this means that I can write a small function using only the entity of concern without any setup/teardown/transaction, drop the DLL in the software directory and it is immediately available for use with all the plumbing and background technical details taken care of.  The time it would take to do this before following practices and patterns would be an hour or two, time now is five to ten minutes.  This means that I can rapidly meet my customers feature requests, and installation of a new feature can be as easy as dropping a DLL into a directory.  I did not give up any control or dumb anything down, you can still dive as deep as you want when necessary since the application is composed together in modules, of which any one can have functions overridden / modified etc. when necessary.  This is not necessary 100% of the time.

Now the question arises as to what I do when I need to muck around with this transaction manager code since I have run into a scenario where it needs to be executed differently.  My objects are composed from different pieces using factories or strategies and so if I am creating something where I need some custom transaction manager code I can create a new section of code that adheres to the transaction manager interface that I set up and this will be used with the object.  Or I can use the template pattern and override the default functionality ONLY when necessary.  This allows me to have only the transaction manager code appear once for each scenario, and allow full control over what happens.  Properly structured code allows you both have simplicity and access complexity when you need to.  Properly structured code allows for better maintenance and faster time to market for features.

And all of this is fine, and I really do not care for my own purposes since I have already done like dgorsman said: I created my own simplified interface.  You may be thinking I gave up some control or functionality.  I did not, I still have full control over everything it is just structured in a way that makes it more maintainable and quicker to write code.  I suggest you to read and understand patterns and practices, and try them out.  You will only *get* it once you start applying it and seeing how the different workflow actually makes coding life so much better.

So this is what lead me to the original post, if you are actually following design patterns and modern programming principles then you will end up at the same point I am at, NOT because it is how I imagine the API should be, but how proper programming techniques that have been developed over the years dictate it should be.  (Although this in itself can be a hotly debated topic: See coding cowboys VS. architect astronauts, I feel someplace in the middle of these two extremes is probably a good balance.  You don't want to spend all your time applying patterns to every little thing, but you want them to a certain extent for their benefits)

So any programmer that uses these techniques for better coding will arrive with a similar framework, which is the question I am asking, why do we all need to repeat the same process to arrive at this point?  If you do not apply patterns and practices then please ignore all my posts as what I am talking about will not apply to you.  I have seen and can only imagine the amount of AutoCAD .NET code out there that is horribly written.  The stock API makes people falling into horrible coding practices VERY easy.

I ended up with my own framework where I do not need to worry about the transaction manager code that appears in bulk everywhere and this is the way the API could be.  New programmers using my code can rapidly get going and when they get advanced enough and learn enough that they need more deeper access to functionality it is all still there, just not all spaghetti in your face mess all the time.

Definitely the API as it exists is the way it is from where it comes from and the wrapping that is done, so what I am talking about would not be a replacement or a this is how it should have been done.  It would likely be another namespace that encapsulates modern design principles with the existing API, and as such IMHO should have been implemented by now in some shape or form.  This would allow the community in general to be writing code that does something instead of boiler plate transaction code.  Just think about how many times how many people have written that transaction code, and de-bugged it when they were off on something.  We could have collectively created an open source API that addresses this ten times over.

These are some of the features my code now has by following separation of concern principles, research other pattern keywords above to find out why you would want to use them (taken from http://aspiringcraftsman.com/2008/01/03/art-of-separation-of-concerns/):

"Applying the principle of separation of concerns to software design can result in a number of residual benefits. First, the lack of duplication and singularity of purpose of the individual components render the overall system easier to maintain. Second, the system as a whole becomes more stable as a byproduct of the increased maintainability. Third, the strategies required to ensure each component only concerns itself with a single set of cohesive responsibilities often result in natural extensibility points. Forth, the decoupling which results from requiring components to focus on a single purpose leads to components which are more easily reused in other systems, or different contexts within the same system. Fifth, the increase in maintainability and extensibility can have a major impact on the marketability and adoption rate of the system."

---

After all "Prior planning prevents p__ poor performance" hold very true the more complex software gets.

---

This is exactly what I am trying to get at.  The words "refactor" and "design patterns" was unknown to me when I started programming and once you see how they work and the importance of building loosely coupled software you see the power and simplicity that can co-exist when you do enough prior planning.

I am not rallying against the API, I am pondering why so many people need to duplicate so much effort to arrive at the same place.  This almost screams open source project, but from the tone of the posts I am sure there is a small percentage of architecture oriented programmers working with AutoCAD and the value of these practices and principles are probably lost on them.

[Anonymous]

I'm with you tonosteel. I dare say the reason why these others do not get it is partially how we are in this predicament. Autodesk would not be what it is today if they had started out making things this difficult. It would be nice to have something like what Processing does for Java.

[DiningPhilosopher]

It would be nice if there was nice, clean, high-level API (like ActiveX but without so many limitations), but that would entail quite a bit of work, and given Autodesk's demonstrated lack of interest in supporting AutoCAD-based solutions (that tend to compete with other Autodesk products), and the low priority that vanilla AutoCAD has these days there, don't hold yer breath.