.NET
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Standalone Exe to Convert DXFs to DWGs

5 REPLIES 5
Reply
Message 1 of 6
egcallis
898 Views, 5 Replies

Standalone Exe to Convert DXFs to DWGs

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):

 

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

 

 

 

 

5 REPLIES 5
Message 2 of 6
norman.yuan
in reply to: egcallis

Slowness (compared to your previous VBA (in 32bit Acad) code is what you get when choosing COM automating Acad from external EXE app, because your EXE app and Acad run in different processes and the communication between your app and Acad must travel through process boundaries. It would not be surprise me if your EXE is 5, 10, 20 times slower than your previous VBA code running inside Acad when doing the same job.

 

If you insist of doing EXE app, your coice of speed thing up would be

 

1. Directctly manipulate DXF file as ACSII/TEXT file;

2. Use ObjectDBX to manipulate drawing (i.e. without opening the drawing in AutoCAD editor, but you still need a running Acad session). This way, the slowness caused by loading drawing file visually is eliminated. However, you will not be able to Zoom to Extents as you required.

 

To your questions:

 

1. You do not need other references. You cannot directly access drawing database exposed in .NET API. You only deal with ACAD COM object model

2. "Net Transaction"? if you refer to Database/Transaction exposed in .NET API, no, you cannot use it in EXE app. Well, if you go deep, you could do .NET DLL with .NET API and then expose it as COM, then call it from your external EXE. But, what is the point: you still automate it from external app/out-proccess, which is slow!

 

IMO, it is arguable that just because there are a lots of DXF file to provess then you must use EXE to automate AutoCAD.

 

With the all DXF/DWG manipulating done inside AutoCAD with .NET API, you still can automate entire process:

 

1. create an EXE, it only does one thing: start AutoCAD session and make sure the .NET DLL is netloaded (say, with specific acad.lsp).

 

2. Once the .NET dll loaded, it will take over the Acad session and start DXF processing inside AutoCAD until the batch process done and close Acad session (if you choose so). No out-prcess to the startup EXE, so no the slowness caused by cross-process communication.

Message 3 of 6
egcallis
in reply to: norman.yuan

Okay, so then I'll create a new class type project, reference in the ObjectARX files, and get the code running in AutoCAD. Then worry about starting AutoCAD and lauching the dll.

Message 4 of 6
StephenPreston
in reply to: egcallis

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.
 
BTW You can setup Demand Load registry settings to allow your .NET DLL to be automatically loaded when AutoCVAD launches. You can even expose a COM Interface from your DLL that your external app can call to perform some operationn (e.g. your exe could call your DLL interface to tell it to load and process your DWG/DXF file).
 
Cheers,

Stephen Preston
Autodesk Developer Network
Message 5 of 6
SENL1362
in reply to: egcallis

We have a comparable VBA program converting drawings according to a set of input rules read from a ini file using the flexibility of VB's dynamic interpretation.

 

We are rewriting this into C# using Reflection to convert and compile the rules into a DLL, this is supprisingly fast ( far less than 1  second).

Then this DLL will  be loaded and executed dynamically and runs about as fast as a normal loaded .net project.

(First tests indicate an improved performance from 30 seconds to convert in VB  to 1 second in C#. No need for a progress bar  anymore)

 

This approach keeps the "flexibility" of VBA where users may change the input rules and it keeps the speed of .net preserved.

To show you the functionality here are a few input rules

 

 Convert=c:\temp\Convert\*.*
 InsertDWG=GenImportTemplate.dwg
 InsertSymbol=G-H-Waterkruising(x=10,Y=15,rot=30,scale=3,explode)
 Color=ByLayer
 ?Type=Text;TextStyle=Gen;TextHeight=2.5
 ?Block=!(ModelSpace|PaperSpace);Layer=0
 ?Layer=PLANNED_;Layer=Topo_geplanned
 ?Type=Text;Layer=Topo_txt
 ?Layer=Adres;delete

 ?Type=polyline;LTGEN=true

 ?Layer=^E_;Layer=E-O~Best_Sym-dik

 ?Type=Text;?TextHeight=>2;?TextHeight=<=3;Layer=Tekst25;Color=Bylayer

 ?Type=(Line|Circle|arc);?LineType=Phantom;?Color=Rood;Layer=Phantom18;Color=ByLayer;LineType=ByLayer

 ?Type=insert;?name=E_LV_DIM_COMPONENT_.*922;ReplaceSymbol=E-O-Maatpijlpunt;layer=E-O~Best_Maat

 ZoomExtents

 

All rules are applied on all entities

Rules are divided in "tests" and "settings" separated by ";"

Tests starts with ? and test the property of an entity i.e. ?layer=Adres  test the layername of the entity for the pattern Adres. the value of a test is a regular expression.

Settings sets the property of an entity, i.e. Layer=0 puts the entity on layer "0".

When a test failed the rest of the line of the input rule will be skipped, i.e. ?Type=Text; only enititytype of Text will be  matched and thus the rest of the line apply only on text entities "?TextHeight=>2;?TextHeight=<=3;Layer=Tekst25;Color=Bylayer

 

To prevent conversion and compilation every time when the same input rules are used we calculate a checksum and add this to the DLL. So if the DLL exists and has the same checksum we can start the conversion without conversion and compilation of the DLL.

 

hope this also may help you to create a speedy program.

 

 

 

 

 

 

 

Message 6 of 6
egcallis
in reply to: SENL1362

Thanks to all.  I simply created a new project (Class DLL), added the ObjectArx 2010 references, Added the CommandMethod to show the main form and It runs at the same speed that it used to. in VBA (but faster cause I'm using a machine with more juice).

 

Now I'll just work on getting code to launch AutoCAD, netload the DLL, and run the init command to start processing. 

 

 

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th


Autodesk Design & Make Report

”Boost