Author Topic: Referencing AutoCAD .NET code from Windows forms application  (Read 300 times)

0 Members and 1 Guest are viewing this topic.

DjJazzyJeffTN

  • Mosquito
  • Posts: 4
Referencing AutoCAD .NET code from Windows forms application
« on: August 01, 2017, 11:44:19 am »
I have an Access frontend application that I have developed. I have been going through to change the front end application to a VB windows forms application. Is there a way to access the custom commands in an AutoCAD NETLOAD dll to control the AutoCAD application? When I say control I mean run commands and such. Thanks in advance.

I did try and post this to https://forums.autodesk.com/t5/net/accessing-net-commands-from-outside-of-autocad/td-p/7268603 , but it did not seem to work for some reason.

Update: The frontend application manages all of our 7000+ AutoCAD isometric drawings. Giving the user AutoCAD functions if they are an AutoCAD user.

Functions:
  • Save a revision of a drawing
  • Standardize Layers
  • Import specific blocks and their attribute information
    • This is also used to check a larger database where the attributes should match a database record
    • This check shows you a health check on your evergreen AutoCAD drawing.
  • Function to add the specific block with the appropriate attributes to the drawing.
  • Allows user to add a revision entry for a drawing.
    • User can then attach any filetype that they would like to support the revision. (ex: PDF red line)
  • Allows non-AutoCAD users the ability to update titleblock information in the frontend application. Which, creates a list of changes for an AutoCAD user to come back and push into the drawing at a later date.

The current access frontend application uses late binding in order to manage multiple AutoCAD versions and Non-AutoCAD users. It works, but I am missing the functionality of AutoCAD Application and Document Events. The current way that I solve this is with an AutoCAD VBA project which i copy and update the references for AutoCAD 2014 & 2015. It just seems that there should be a better way to accomplish this.
Event Functions:
  • Create PDF on drawing save.
  • Index Block information on drawing close.

I am sure that I will get responses saying that I am crazy for doing this, but it has become a very useful application for us. Maybe it is not possible to complete this utilizing .NET and that i should be using COM. The .NET dll that I have created works on both AutoCAD 2014 & AutoCAD 2015. I like the idea of only managing one dll to supply all of the AutoCAD functions. Anyways, I am rambling on, but I appreciate any help that you can give on this subject as I am lost in a sea of code.
« Last Edit: August 01, 2017, 12:30:51 pm by DjJazzyJeffTN »

n.yuan

  • Bull Frog
  • Posts: 234
Re: Referencing AutoCAD .NET code from Windows forms application
« Reply #1 on: August 01, 2017, 04:54:09 pm »
If you insist doing an external EXE application, then you can only use AutoCAD COM API, not AutoCAD .NET API.

There are 2 cases you can somehow integrated AutoCAD .NET API code with your EXE solution:

1. Create a bunch of custom commands with Acad .NET API and make sure they are loaded on AutoCAD startup. Then your EXE App, you use COM API's AcadDocument.SendCommand() to call there custom commands;

2. Do your code in AutoCAD .NET API, and expose it to COM, so that your EXE app can call the COP wrapped .NET API code.

I'd would not do either of them, though.

From your description, it looks like the functionalities your solution provide are mostly for an AutoCAD user, who runs AutoCAD (and your application must work with a running AutoCAD session). So, if I am the AutoCAD user, why do I need run a side EXE application to do the work that can be done in AutoCAD easier, faster?

All the tasks you listed can be done in an AutoCAD Add-in developed with AutoCAD .NET APIs, this way, you not only have a more powerful API support (.NET API vs COM API), but also eliminated extra layer of application (the external EXE app).

MickD

  • Gator
  • Posts: 2931
  • I don't need a job, I need Money!!
Re: Referencing AutoCAD .NET code from Windows forms application
« Reply #2 on: August 01, 2017, 05:42:24 pm »
I agree with n.yuan and would like to add that it sounds like your database is too tightly tied to your Front End app. Most of the functions you mention are CAD specific except for the title block updates which you have covered.
I'd imagine there are many more commands for the front end app that are not so CAD related and that's why it makes sense to have it stand alone.

Either way, you need to 'separate your concerns' as they say. You need to separate your 'model' (database) functionality into a separate dll, your 'front end' (view) into its own app and create a CAD plugin dll for your CAD functionality. Both the Front End and CAD app reference in the database dll so they are both using the same db code.

Maybe you can leave your Access front end alone and just call the Access db directly from CAD and make a thin UI in your CAD plugin as required?
"A language that doesn’t have everything is actually easier to program in than some that do."

        — Dennis M. Ritchie

dgorsman

  • Water Moccasin
  • Posts: 2227
Re: Referencing AutoCAD .NET code from Windows forms application
« Reply #3 on: August 01, 2017, 06:30:11 pm »
I'm leaning in the same direction - factor out the CAD stuff for CAD, factor out the UI stuff for the external application, and factor out the database stuff to be referenced by both.

Although I'm sorely tempted to recommend keeping the "non-CAD" people away from the drawings entirely.  If you need to build a whole front-end which hides AutoCAD so they can do something correctly, they probably shouldn't have access to the drawings in the first place.  They should have something more appropriate to be working on.

And yes - I *do* work with iso's, P&IDs, and engineers of various stripes.  We have CAD people doing a lot of what you're describing here inside CAD.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

nullptr

  • BricsCAD
  • Needs a day job
  • Posts: 6735
  • AKA Daniel
Re: Referencing AutoCAD .NET code from Windows forms application
« Reply #4 on: August 01, 2017, 08:39:59 pm »
an alternative might be realdwg or ODA’s stuff

DjJazzyJeffTN

  • Mosquito
  • Posts: 4
Re: Referencing AutoCAD .NET code from Windows forms application
« Reply #5 on: August 02, 2017, 09:45:27 am »
Although I'm sorely tempted to recommend keeping the "non-CAD" people away from the drawings entirely.  If you need to build a whole front-end which hides AutoCAD so they can do something correctly, they probably shouldn't have access to the drawings in the first place.  They should have something more appropriate to be working on.

So the Frontend databases main purpose is to keep track of drawings and their revisions. Most of these "Non-CAD" users are the ones doing the as-built walkdowns. The frontend does not hide AutoCAD. When a "Non-CAD" user opens a drawing, it just uses their default dwg viewer to open the drawing. Those users have read only access to the CAD files anyway. Maybe they do and maybe they do not need access to the AutoCAD drawings. I could give them access to the PDFs just the same, since everytime an AutoCAD drawing is saved a PDF is created in a sister directory.

The reason that the AutoCAD commands exist inside of the frontend application was just for ease of use. It is much easier to click on a button to open a drawing in the database that is telling you to do the work than to navigate the folder structure right?

I have attached a screenshot of the frontend application so that I might be communicating what this does more clearly. Again the purpose of this application is not to control AutoCAD, but to keep track of the status of all of our evergreen AutoCAD drawings. Controlling AutoCAD for the "CAD" users is just to help with navigating the drawings more quickly.

As I am thinking about this, I could just implement the Late binding technique that I have already completed in the Access Application. What I think that I was really trying to accomplish is the ability to capture the event handling. For instance, creating a PDF at the completion of saving a drawing. Indexing the blocks and their attributes when the drawing closes. I have been completing this with AutoCAD VBA, but I was trying to package all of the Code together in the frontend application.


DjJazzyJeffTN

  • Mosquito
  • Posts: 4
Re: Referencing AutoCAD .NET code from Windows forms application
« Reply #6 on: August 02, 2017, 10:00:28 am »
an alternative might be realdwg or ODA’s stuff

I looked into both of the above recommended options. Those are really cool, but I don't know if that is what I am looking for. I still only need to users with AutoCAD to do any modifications to the drawings. Am I missing a way that these suggestions would be a good option. Thanks in advance!

DjJazzyJeffTN

  • Mosquito
  • Posts: 4
Re: Referencing AutoCAD .NET code from Windows forms application
« Reply #7 on: August 02, 2017, 10:46:19 am »
1. Create a bunch of custom commands with Acad .NET API and make sure they are loaded on AutoCAD startup. Then your EXE App, you use COM API's AcadDocument.SendCommand() to call there custom commands;
I have done this before and I have been able to successfully do this with the normal commands, but not with my custom commands. My AutoCAD dll does load at startup, but the command does not execute when I send the AcadDocument.SendCommand("whatever"). I will look more into this option to see what I am doing wrong with either my frontend application or my dll.
***Update I am able to do this with my custom commands that are located in the assembly file.

2. Do your code in AutoCAD .NET API, and expose it to COM, so that your EXE app can call the COP wrapped .NET API code.
This was an option that I really wanted to accomplish, but I could not find any solution to get the commands through the running AutoCAD application. I am also guessing that you did mean "COM" instead of "COP" wrapped correct? I did Google "COP wrapped .NET API code" and found a number of police results.

I also tried loading the AutoCAD dll as a reference in my frontend application. This gave me the commands, but it was like it was empty. I do not know how to associate it with AutoCAD. The dll is loaded using NETLOAD and everything. There is something that I am just too inexperienced to understand.

I appreciate your feedback and would love any guidance that you could provide on accomplishing the second option preferably.
« Last Edit: August 02, 2017, 04:50:32 pm by DjJazzyJeffTN »

n.yuan

  • Bull Frog
  • Posts: 234
Re: Referencing AutoCAD .NET code from Windows forms application
« Reply #8 on: August 03, 2017, 01:22:04 pm »
......
2. Do your code in AutoCAD .NET API, and expose it to COM, so that your EXE app can call the COP wrapped .NET API code.
This was an option that I really wanted to accomplish, but I could not find any solution to get the commands through the running AutoCAD application. I am also guessing that you did mean "COM" instead of "COP" wrapped correct? I did Google "COP wrapped .NET API code" and found a number of police results.

I also tried loading the AutoCAD dll as a reference in my frontend application. This gave me the commands, but it was like it was empty. I do not know how to associate it with AutoCAD. The dll is loaded using NETLOAD and everything. There is something that I am just too inexperienced to understand.

I appreciate your feedback and would love any guidance that you could provide on accomplishing the second option preferably.

Yes, "COP" is a typo, should have been "COM". While I list it as an option, in reality, as far as I know, it is rarely used, especially for AutoCAD .NET programming. I did once long time ago, trying to prevent significant update to an old VB5/6 application that automates AutoCAD via AutoCAD COM API (similar to your case, even your app is done with VB.NET). You can search the net for "exposing .NET to COM" for more technical details. In the early era of .NET, it might have had more use, because at that time, there are a lot of existing application based on COM, so it made sense to incorporate new technologies (.NET) into existing applications (COM). but, in the end, it is very likely that it is more pain than good: because you really need to manage 2 set of DLLs (the .NET ones, and the COM wrappers, which also need to be registered at running computers with regsvr32.exe each time you have interface-breaking update). That is why I said "I would not use" it in previous reply, and probably I would never use it in future.

I strongly agree with the suggestion from other replies that you apply "separate concerns" approach to your solution's structure: operations meant for CAD users and require AutoCAD involvement should be placed in AutoCAD add-in with corresponding UI; operations that do not involve AutoCAD (in your case, I can imagine, things like setup data in database for title block update, such as which block to be updated, which attributes in a block get what data...), then can be managed in a stand-alone EXE application. So, the CAD users do not have run extra app to get drawing updated, and CAD management can set up something without bothering running AutoCAD unnecesarily, and you have clean applications to maintain.