Thanks for the tip, but I'm not sure this will work as I'm using COM to access AutoCAD..?
Gah! I wish I had been here to help when this was relevant. For anyone still wondering about Batch-
printing anything via interop, there's a general pattern that fits most scenarios:
- Instanciate or latch onto an AutoCAD session
- Netload your custom in-process assembly with fast in-process code for printing (or doing anything for that manner)
- Loop the drawings from the COM side so you can talk directly to your UI (progress update delegates come to mind), opening them one at a time from interop, and calling your named CommandMethod via send command (or registered ServiceComponent).
- Exit AutoCAD from COM
- Profit
A few things to note:
1. Having a custom .arg profile for automation can really make a nice difference in speed and control here.
2. COM is slow. However understand where the speed matters. Calling 'Open' on a drawing from COM vs managed in-process code is pretty much negligible, since the drawing having to load off the disk is the limiting factor. Running any sort of DbObject manipulation, searching for data, or creating new objects is where you REALLY want to stay away from COM.
3. In regards to printing, understand that (at least when I tested it in 2010) the in-process printing instanciates a separate session of AutoCAD to plot from. (I would really love someone to chime in with more about this, specifically whether or not this is in our control). There's a case to be made for batch-PDF plotting being faster this way, but I was never comfortable eating up the extra resources, and not having a direct hold on the new acad.exe instance. During regular paper plotting, even COM printing calls aren't terrible in my opinion. Stacking the print queue with 30 drawings in 10 seconds vs 60 seconds really doesn't matter unless your plotter can keep up with the speed the jobs get added to the queue. ** Generally ** (not saying you shouldn't try to make things as quick and efficient whenever possible, but pick the right battles when you're writing code).
4. You can cheat a little to get simple COM to in-process communication by setting up prompts inside your defined CommandMethod. This way when you invoke SendCommand from COM, you can include your parameters in a single line:
(Command "MyCircle 0,0,0 5\n") // Or something... don't judge me
Anything that you can parse from a string is fair game.
5. Avoid using Interop libraries. Seriously. In the context of all Office products and AutoCAD, there's really no need to ever use them. Use reflection or dynamic members, and you've pretty much kicked version dependence in the face. What I'll typically do is add in an Interop assembly when I'm not comfortable with the classes and methods, write the code just like I'm leaving the interop libraries in. When everything is working the way I've intended, I'll strip out the libraries and make the replacements. When using .NET 4.0, this can literally be as little as 3-5 lines of code. There are instances where the underlying COM classes/methods change from one release to the other, but you can deal with those on a case-by-case basis and never have to worry about maintaining multiple releases.