Topic: Standalone Exe to Convert DXFs to DWGs

[egcallis]

I'm developing on a W7 64bit machine  using VS2010 and AutoCAD 2010. Using COM, I've converted a VBA application into an .exe that runs but it is very slow (much slower then the 32bit VBA code used to run). Since we produce a lot of DXFs out of our 3D application, we want the conversion to be automated (hence, no more running inside of AutoCAD).

The current version just references the AutoCAD 2010 Type Library and the AutoCADObjectdbx COMs.

For each DXF, the code does the following:

   1. Adds new layers
   2. Loops thru all entites (currently using a selectionset)
       a. Changes the entity's layer based on a collection key and it's linetype to "bylayer"
       b. For PolyLines and LWPolyLines, sets the constantwidth to 0
       c. For all Text, changes the style to "SIMPLEX", the Scalefactor to 0.7 and looks for a special text value which
           indicates the drawing scale ("dscale").
    3. Sets the drawing's DIMSCALE and LTSCALE to a multiple of the "dscale"
    4. Scales all entities by "dscale"
    5.  Purges All
    6.  Zoomextents()
    7. Saves the drawing as a *.dwg file
    8. Closes the drawing
    9. Logs some statistics on each file converted.

It seems as most of the time is spent in Step 2. I can obviously do steps 2,3 & 4 by reading/modifying  the DXF as a text file very fast. But I would rather keep all the processing inside of AutoCAD.

So here are my questions(based on using COM) and trying to speed the process up:
 
1. What additional references do I need work directly with the drawing's database?
2. Are the NET transaction examples under this category valid when going through COM?

I've zipped and attached the current project (VS2010 project)  for possible reference

Thanks,

Eric

[Odoshi]

As soon as you make a stand-alone EXE, you are stuck with using COM. (No AutoCAD.NET libs)

What you lose is the ThisDrawing object. You'll have to tweak your code around that if you used it.

If you go back inside of AutoCAD, and make a .NET DLL, things willl run faster, but is almost a complete rewrite.

HTH,
Mike

[SGP2012]

The slowness will be primarily because you're making COM calls across process boundaries. When you're referencing the AutoCAD and ObjectDBX Type Libraries, you're are still running AutoCAD in the background - its just invisible - take a look in your Task Manager.

For optimum speed, I'd recommend either:

1. Go back to running your code inside AutoCAD. Your calls to the AutoCAD COM API will be at least 10 times faster if you're not marshalling them across process boundaries.
2. If you really don't want to run AutoCAD (or even require that AutoCAD be installed for your app to run), then consider buying a license for the RealDWG SDK (www.autodesk.com/realdwg). This allows you to embed DWG/DXF read/write capability directly into your app. Its .NET or unmanaged C++ only, but you can use the COM API via .NET COM Interop.

[Keith™]

Yep .. marshalling is what is causing the poor performance, since the stand alone executable is running in a separate process.

After looking at your code, I see that you are doing other operations besides simply converting between file types. If you really want to pursue this avenue, you will have to write lots of code to manage things that are simple to do when it is run as a process inside AutoCAD.

If not letting the user see the AutoCAD window is a requirement, you can rewrite the code as a .net assembly that operates within AutoCAD, but instead of loading AutoCAD and running the application, create a loader that loads AutoCAD, causes AutoCAD to load the .net assembly and then executes your command.

The main problem with this approach is that the visibility of the AutoCAD screen cannot be ensured to be invisible for the entire process. You may have to tweak the code to ensure it remains hidden.

[egcallis]

Hee hee. Love the sig line