How to give the user progress bar feedback for AutoCAD applications? (Using WPF)

[Millerni456]

Okay, since my previous question is no longer alive on this forum, I'm going to post a new questions that is more specific towards the goal I am trying to achieve.  You can view the previous question here:

http://forums.autodesk.com/t5/NET/Rejected-COM-Call-in-WPF-using-a-Background-Worker-Thread/m-p/4777...

My objective is to create an AutoCAD program (that connects using either COM Interop or NETLOAD) which has a WPF interface and allows the user to automate processes on hundreds of drawings.

Anyways, since the user will be running this program for a significant amount of time, he or she will need to know how close the program is to finishing.

My question to you here in the Autodesk community is this:

How can I intregrate progress bar feedback into my applications?  If this isn't possible, can you think of other ways to give the user feedback while the program is running?

PS:  I've looked around a lot and I know how to do progress bar feedback and AutoCAD development separate from one another.  Apparently, there is impatibility among my methods of feedback (using background threads) with AutoCAD.  I've tried connecting to AutoCAD using COM Interop and reimplemented the message filter so the program works with WPF properly.  I've also tried connecting internally, using NETLOAD, to generate a WPF window.  In either case, I cannot achieve the desired result by using a background thread to do processing.

Your help is greatly appreciated.

God Bless,

Nick

[StephenPreston]

Hi Nick,

Does this blog post help at all - http://adndevblog.typepad.com/autocad/2013/01/taskdialog-with-progress-bar.html ?

Also, because it isn't completely clear to me what your architecture is, thought I'd mention a couple of things just in case (although I expect you already know this):

1. The AutoCAD API is not multithreading safe - so make sure you don't make calls to our API from multiple threads (spawning worker threads is fine, just only access the API from the main thread).

2. For batch processing, its best to spawn a separate instance of AutoCAD for each task in the batch, and monitor the process to make sure it hasn't crashed or stalled (rather than expecting your main application to remain stable forever).

[norman.yuan]

I am not sure I understand your question correctly or not: you have a stand-alone app (EXE) that automate an AutoCAD session to process a set of drawings. And you want the AutoCAD session runs as different thread and gived processing feedback to the EXE app.

Firstly, I am not a fan of automate AutoCAD for batch processing. You see, AutoCAD is quite comlicated desktop app, and when opening many drawings in a row, a lots of unexpected things could happen that may stall AutoCAD and requires user interaction. Maybe, using AutoCAD console, avialable since 2013, would avoid many of these troubles because the AutoCAD UI is excluded. Also, using RealDwg for drawing data batch processing is really more technically sound solution.

Secondly, If you do go with AutoCAD automation (via COM, of course), I really do not see much advantage of running AutoCAD iin differnt thread. All AutoCAD user know, when AutoCAD run in its full power iin a computer, it is really hard to run anything else smoothly. If I have to automate AutoCAD with exe, I'd like my user see the AutoCAD session runs, and disable the exe current UI, expect for the progress bar/message label/text, and the "Stop" button.

You can easily use BackWorker component to run AutoCAd session in another thread and feed back the progress to your EXE, be it WinForm or WPF app.

I have tried a simple concept-proving project that works as expected. If you are interested in it, I can make it downloadeable from my google drive later (because this forum does not allow code file/zip file to be attached).

[Millerni456]

Hi, I just want to get back to you both seeing as I haven't had much time to investigate the options you have both presented.

FYI, I'm running 64-bit version of AutoCAD 2012

@Stephen Preston

I'm interested in looking into the TaskDialog option you have mentioned.  So far, I have attempted to modify one of my programs to create separate instances for each task in the batch; ultimately, this didn't work as expected.  Essentially I've set up a simple algorithm for doing this:

- Create a new instance of AutoCAD (using COM).

- Open the current drawing within the batch.

- Perform operations on the drawing, then save and close.

- Close the default drawing ('Drawing1.dwg').

- Quit AutoCAD, then increment the current drawing.

This appears it should work well, yet the AutoCAD instance fails to be created for the second drawing.  The entire algorithm was put into a separate thread so my application's UI is not connected to AutoCAD, thus allowing feedback.

As of now, I have the application working without feedback and it performs very well.  It iterates through the batch data very fast.  If I create a new instance for every drawing, won't this slow down the completion time due to the startup/cleanup of AutoCAD?  Regardless, I am able to cope with the drop in time efficieny granted the user can have feedback.  This will help my users to have less confusion while running these types of programs.

@Normal Yuan

Yes! I am definitely interested to see what you have setup to test this concept.

Unfortunately, I'm running on AutoCAD 2012, so AutoCAD Console is not a viable option unless we upgrade to AutoCAD 2013.  Also, it doesn't seem feasible to install all of our computers with RealDWG as well.  In any case though, I'm curious if RealDWG can also modify the AutoCAD database.  After doing some quick research, it was unclear what that software could and could not do.

The advantage of running AutoCAD in a different thread has to do with making the WPF form responsive, as well as able to display feedback changes.  While in a single thread, the WPF UI does not update my progressbar (graphically) until the AutoCAD processing is finished.  This progress bar is useful to the user because it shows how much longer they have to wait for processing to end.  When you say "except for the progress bar/message label/text, and the 'Stop' button.", are you updating your feedback in the same thread AutoCAD is running in?

Anyways, I am really interested in seeing how easy it is to have a backworker running AutoCAD while giving feeback, as this has provided me many difficulties.

Thanks to you both for your responses.  I greatly appreciate the time you are investing into helping me with this struggle.

[norman.yuan]

OK, I'll post back a link for downloading my test code as soon as I can.

[norman.yuan]

Here is the link to download the code of my test projects.

Some explanation:

The project includes 3 projects:

1. DLL that automates AutoCAD with or without BackgroundWorker.

2. A WinForm app. There are 2 buttons to Automate AutoCAD with or without BackgroundWorker

3. A Wpf App that automate AutoCAD with BackgroudWorker.

Both WinForm and Wdf app start AutoCAD session (with or without BackWorker), and open 4 drawings one-by-one (drawing are included in each app's Bin folder), and dosomething with the drawing (I used Thread.Sleep() instead), and then close the AutoCAD session.

In all cases, the progress bar on the UI form (wther the BackgroundWorker is used or not) are all displayed well.

I used AutoCAD 2012/VisualStudio2012. Just make sure the DLL has correct references to AutoCAD COM interops.

HTH.

[StephenPreston]

I've attached an old ADN 'Plugin of the Month' sample that demonstrates launching multiple AutoCAD instances to run a batch process. The current version of the app is being maintained by JTB World and can be obtained from the Exchange store - http://apps.exchange.autodesk.com/ACD/en/List/Search?query=batch+publish&facet=&collection=&sort=dat...