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

Progress Bar (C# .NET)

17 REPLIES 17
Reply
Message 1 of 18
rdswords
2891 Views, 17 Replies

Progress Bar (C# .NET)

I'm writing a class library that defines an AutoCAD command. Within the method executed by the command, I'd like to call upon some sort of progress bar that will center itself onscreen and maintain focus over AutoCAD. While the progress bar is being displayed, I want the method to continue to execute in the background, and periodically update the progress value.

I can just manually set the progress value at different points within the code, but I'm stuck on how to display a progress bar without being in a form-based application. Can anyone recommend an approach to displaying a progress bar from within a class library(.dll)?
17 REPLIES 17
Message 2 of 18
Anonymous
in reply to: rdswords

Not sure what you mean by 'without being in a form-based application'.

ClassLibrary's (DLLs) can have forms in them too.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009
http://www.acadxtabs.com

wrote in message news:5891919@discussion.autodesk.com...
I'm writing a class library that defines an AutoCAD command. Within the method executed by the command, I'd like to call upon some sort of progress bar that will center itself onscreen and maintain focus over AutoCAD. While the progress bar is being displayed, I want the method to continue to execute in the background, and periodically update the progress value.

I can just manually set the progress value at different points within the code, but I'm stuck on how to display a progress bar without being in a form-based application. Can anyone recommend an approach to displaying a progress bar from within a class library(.dll)?
Message 3 of 18
rdswords
in reply to: rdswords

Well, lets say I tag a command method in my class library. I also add a form to my project in VS. I configure it as a borderless form with a ProgressBar control on it. I can create an instance of the form in my command method, and then show the form. From this point, the form will halt the command method and begin running it's own methods right? I.e. I won't be able to continue with code in my command method until the form closes? Do I need to move my procedural code over to the form? If not, can the progress bar on the form be accessed by my command method, or just from within the form?
Message 4 of 18
Anonymous
in reply to: rdswords

You can handle an event of the form (e.g., Activated), and from the event handler, you call your process code that runs while the form remains visible, and have that process code intermittently update the progress bar. When the process is done just call Close() on the form.

Add a public method to the form that you can call from the outside to update the progress bar while the process is running.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009
http://www.acadxtabs.com

wrote in message news:5892633@discussion.autodesk.com...
Well, lets say I tag a command method in my class library. I also add a form to my project in VS. I configure it as a borderless form with a ProgressBar control on it. I can create an instance of the form in my command method, and then show the form. From this point, the form will halt the command method and begin running it's own methods right? I.e. I won't be able to continue with code in my command method until the form closes? Do I need to move my procedural code over to the form? If not, can the progress bar on the form be accessed by my command method, or just from within the form?
Message 5 of 18
Anonymous
in reply to: rdswords

Tony Tanzillo wrote:
> You can handle an event of the form (e.g., Activated), and from the event handler, you call your process code that runs while the form remains visible, and have that process code intermittently update the progress bar. When the process is done just call Close() on the form.
>
> Add a public method to the form that you can call from the outside to update the progress bar while the process is running.
>

I did exactly the same in a very recent past using delegates - we used
progressed bar control - except that updating the progress bar
intermittently doesn't work as expected. For one, during performing time
consuming task, the progressbar control doesn't refresh even if it was
updated. I worked around this by placing an AVI movie animation instead
of progressbar and played it as progressbar. I thought it was just too
heavy weight. So finally I replaced the movie by an animated GIF
(created from the AVI movie using MS' GIF Animator). Works perfect.

-Gagan
Message 6 of 18
caddie75
in reply to: rdswords

Hi Gagan,

Have You tried a Refresh on the Progress control, after you changed the value?

I had a similar problem with various counters on a form.
The Refresh helped but if the action in AutoCAD progressed sometimes the form froze. I now have the Actions taken in autocad in a BackgroundWorker, and the form updates the counters perfectly.

A Caddie.
AutoCAD 2008 sp1, WinXP Pro Sp2.
Message 7 of 18
Anonymous
in reply to: rdswords

caddie75 wrote:
> Hi Gagan,
>
> Have You tried a Refresh on the Progress control, after you changed the value?
>
> I had a similar problem with various counters on a form.
> The Refresh helped but if the action in AutoCAD progressed sometimes the form froze. I now have the Actions taken in autocad in a BackgroundWorker, and the form updates the counters perfectly.
>
> A Caddie.
> AutoCAD 2008 sp1, WinXP Pro Sp2.

Yes, I tried that. Also, the major work was being done in a class where
it didn't have access to the form that hosted the progressbar, and I
didn't have time to refactor the code to make it possible. I tried the
classical approach of the use of worker thread and all those jazzy
things, which AutoCAD didn't like very much.

-Gagan
Message 8 of 18
rdswords
in reply to: rdswords

I was making great progress using everyone's advice, but I've hit a roadblock. I managed to create a form that contains a progress bar. My command method just creates and shows the form, and then the form contains all of the rest of the code for the application. To keep the progress bar working well I use a background worker to contain the bulk of the code. However, I may be facing issues like Gagan mentioned. When I hit a line of code that is using interop (trying to change the current profile) the acad.exe process just closes without warning and offers an error report dialog. the following code is a small grouping of the applicable lines (the using statements are at the top of the file, and the rest of the lines are within the background worker method.

using AcadApp = Autodesk.AutoCAD.ApplicationServices.Application;
using Autodesk.AutoCAD.Interop;
using Autodesk.AutoCAD.Interop.Common;

AcadApplication oAcad = (AcadApplication)AcadApp.AcadApplication;
oAcad.Preferences.Profiles.ActiveProfile = "temptemptemp";

The execution blows up at that last line, which was working fine before I used the background worker. Is there something special that I need to consider when I use an interop item in my "backgroundWorker1_DoWork" method"?

In regards to the bigger picture, am I using the best approach to change the current profile? Is there a .NET equivalent for accessing profiles?

These are the last few output lines from debugging in VS:

A first chance exception of type 'System.Runtime.InteropServices.COMException' occurred in UpdateProfile.dll
'acad.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\Microsoft.VisualStudio.Debugger.Runtime\9.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Debugger.Runtime.dll'
The program '[4844] acad.exe: Managed' has exited with code 1 (0x1).
Message 9 of 18
Anonymous
in reply to: rdswords

I have plenty of progress dialogs that update without problem.

To get them to update, you have to call Application.DoEvents().

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009
http://www.acadxtabs.com

"Gagan Gajabaharia" wrote in message news:5892765@discussion.autodesk.com...
Tony Tanzillo wrote:
> You can handle an event of the form (e.g., Activated), and from the event handler, you call your process code that runs while the form remains visible, and have that process code intermittently update the progress bar. When the process is done just call Close() on the form.
>
> Add a public method to the form that you can call from the outside to update the progress bar while the process is running.
>

I did exactly the same in a very recent past using delegates - we used
progressed bar control - except that updating the progress bar
intermittently doesn't work as expected. For one, during performing time
consuming task, the progressbar control doesn't refresh even if it was
updated. I worked around this by placing an AVI movie animation instead
of progressbar and played it as progressbar. I thought it was just too
heavy weight. So finally I replaced the movie by an animated GIF
(created from the AVI movie using MS' GIF Animator). Works perfect.

-Gagan
Message 10 of 18
Anonymous
in reply to: rdswords

I don't have to look at your code to tell you that a BackgroundWorker isn't going to work, because it runs in a seperate OS thread where you can't access most AutoCAD APIs.

If you do what I suggested (start your code from the form's Activate event, after your remove the handler so it doesn't reenter the handler), you should have no problem.

Call Application.DoEvents() each time you update the progress bar to give the form a chance to process messages.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009
http://www.acadxtabs.com

wrote in message news:5893195@discussion.autodesk.com...
I was making great progress using everyone's advice, but I've hit a roadblock. I managed to create a form that contains a progress bar. My command method just creates and shows the form, and then the form contains all of the rest of the code for the application. To keep the progress bar working well I use a background worker to contain the bulk of the code. However, I may be facing issues like Gagan mentioned. When I hit a line of code that is using interop (trying to change the current profile) the acad.exe process just closes without warning and offers an error report dialog. the following code is a small grouping of the applicable lines (the using statements are at the top of the file, and the rest of the lines are within the background worker method.

using AcadApp = Autodesk.AutoCAD.ApplicationServices.Application;
using Autodesk.AutoCAD.Interop;
using Autodesk.AutoCAD.Interop.Common;

AcadApplication oAcad = (AcadApplication)AcadApp.AcadApplication;
oAcad.Preferences.Profiles.ActiveProfile = "temptemptemp";

The execution blows up at that last line, which was working fine before I used the background worker. Is there something special that I need to consider when I use an interop item in my "backgroundWorker1_DoWork" method"?

In regards to the bigger picture, am I using the best approach to change the current profile? Is there a .NET equivalent for accessing profiles?

These are the last few output lines from debugging in VS:

A first chance exception of type 'System.Runtime.InteropServices.COMException' occurred in UpdateProfile.dll
'acad.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\Microsoft.VisualStudio.Debugger.Runtime\9.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Debugger.Runtime.dll'
The program '[4844] acad.exe: Managed' has exited with code 1 (0x1).
Message 11 of 18
Anonymous
in reply to: rdswords

Tony Tanzillo wrote:
> I have plenty of progress dialogs that update without problem.
>
> To get them to update, you have to call Application.DoEvents().
>
Yes, I am aware of almighty DoEvents() 🙂 That didn't help either.

-Gagan
Message 12 of 18
rdswords
in reply to: rdswords

A few things here. I tried the DoEvents() and no background worker and the progress bar never becomes visible until the program finishes the heavy processing. Not only that, but I can't get the progress meter form to go away at the end of the program. I've called Close(), Application.Exit(), etc. and the thing just sits on the screen after the program has done it's thing.

I'm not sure Activated is the right event for this situation. I've got procedural code that only needs to run once and then end the program. Won't activated run the code every time the form appears onscreen (making it possible to accidently run the code more than once)?
Message 13 of 18
Anonymous
in reply to: rdswords

rdswords wrote:
> A few things here. I tried the DoEvents() and no background worker and the progress bar never becomes visible until the program finishes the heavy processing. Not only that, but I can't get the progress meter form to go away at the end of the program. I've called Close(), Application.Exit(), etc. and the thing just sits on the screen after the program has done it's thing.
>
> I'm not sure Activated is the right event for this situation. I've got procedural code that only needs to run once and then end the program. Won't activated run the code every time the form appears onscreen (making it possible to accidently run the code more than once)?
I had exactly the same issues that you are facing now - with the same
questions. I tried a bit to somehow make it work but didn't succeed. I
settled for animated GIF as it met my design goals. Hope someone can
post some code that shows how to make this thing work.
Message 14 of 18
rdswords
in reply to: rdswords

Yes, Tony I'd like to see an example of one of your progress bars if possible. For the life of me, I can't actually get the form to be visible when it's not in a separate thread. And remember, I'm not doing an app where a form sits and waits for events to fire and then executes small chunks of code. I am executing a large chunk of code during which I just want a progress bar to be visible and updated properly. The form doesn't seem to behave when the program isn't sitting idle and waiting for events to fire based on user inputs.
Message 15 of 18
Anonymous
in reply to: rdswords

Here's an example that shows exactly what I described:

http://www.caddzone.com/ProgressDialogSample.zip

Works perfectly for me.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009
http://www.acadxtabs.com

wrote in message news:5893409@discussion.autodesk.com...
Yes, Tony I'd like to see an example of one of your progress bars if possible. For the life of me, I can't actually get the form to be visible when it's not in a separate thread. And remember, I'm not doing an app where a form sits and waits for events to fire and then executes small chunks of code. I am executing a large chunk of code during which I just want a progress bar to be visible and updated properly. The form doesn't seem to behave when the program isn't sitting idle and waiting for events to fire based on user inputs.
Message 16 of 18
Anonymous
in reply to: rdswords

Tony Tanzillo wrote:
> Here's an example that shows exactly what I described:
>
> http://www.caddzone.com/ProgressDialogSample.zip
>
> Works perfectly for me.
>
Thank you, Tony, for the sample code. I checked it out and it works as
expected for me.
Message 17 of 18
Bernd_L
in reply to: rdswords

Hi Tony,

first of all: thanks for your continuing help in the forums. It's great to have someone with your obvious experience helping others with sometimes stupid questions (at least in my case) and thus creating potential competitors 😉
I downloaded your example and it works smoothly as you said, I understand the logic behind it, but both my CSharp and my C++/CLI are too bad to translate it into C++/CLI.
I just can't transform the event handling that is being done in ProgressFormActivated() - and maybe the day has been too long - so if you could provide a sample in C++/CLI I'd be deeply grateful.
Message 18 of 18
Anonymous
in reply to: rdswords

Download the C++/CLI code renderer for reflector from CodePlex, open the compiled DLL and view the disassembly as C++/CLI.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009

http://www.acadxtabs.com

Introducing AcadXTabs 2010:
http://www.caddzone.com/acadxtabs/AcadXTabs2010.htm

wrote in message news:6013677@discussion.autodesk.com...
Hi Tony,

first of all: thanks for your continuing help in the forums. It's great to have someone with your obvious experience helping others with sometimes stupid questions (at least in my case) and thus creating potential competitors 😉
I downloaded your example and it works smoothly as you said, I understand the logic behind it, but both my CSharp and my C++/CLI are too bad to translate it into C++/CLI.
I just can't transform the event handling that is being done in ProgressFormActivated() - and maybe the day has been too long - so if you could provide a sample in C++/CLI I'd be deeply grateful.

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