Link to home
Start Free TrialLog in
Avatar of DrTribos
DrTribosFlag for Australia

asked on

C# Reuse Progress Bar?

Hi All,

Ok dipping my big toe into C#.Net from VBA and would like help / clarification on progress bars and the whole idea of modular programming.

I thought that if I had some-function in a dll and someother-function in someother-dll that decided to add a progress bar to both that I could potentially do this with a single progress bar...

I realise that this might be ambitious for a beginner so what if I have some-function and someother-function in the same ddl?  Is it possible to use 1  progress bar to meet the needs of both functions with a single progress bar?

So far every example that I am able to find on Progress Bars seems to have the function (typically a loop) inside the form that displays the progress bar.

My thoughts are along these lines:

Class1.Function1
Set Progress Min = 1
Set Progress Max = 100

For i = 1 to 100
    Increment Progress
Next i

Open in new window

And
ClassA.FunctionA
Set Progress Min = 1
Set Progress Max = 500

For i = 1 to 500
    Increment Progress
Next i

Open in new window

SOLUTION
Avatar of Miguel Oz
Miguel Oz
Flag of Australia image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of DrTribos

ASKER

You're a fellow Sydney-sider... :-)  

Thanks for you comments, sadly this is pitched slightly above my current skill set.  I understand what you mean by "only 1 instance" but I've no idea how to properly define the progress bar as a property of a class.  It seemed easier in VB.Net.  - but I'm confident that google will tell me if I search for this: "c# set property from another class"

But, how then do I update my progress bar in a meaningful way as I loop through my collection?  I figured it would involve an event of sorts to trigger the background worker?  

If you could provide some pseudo code showing what I should include in my loop I'd be really quite happy (although I should be mowing the lawn or something).
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I'm in the NorWest - just made a compost bin :-D

Thanks for the code, seems easy enough to follow, although some parts confuse me.  For example:

public ProgressBar ProgressBar { get; set; }

On this line there are 2 things called ProgressBar - I'm not sure what each of them are.  I'll try changing the name of one of them and see what breaks.

I'm not sure if I'll get a chance to test today.

Also curious about threads...  Most of what I see uses the backgroundworker, some of what I see suggests alternatives to backgroundworker (WPF?).  I'm assuming that background worker is what allows 2 threads to communicate with each other.  I'm mainly used to working with a single thread in VBA (except perhaps for some events that seem to fire off the side)  but leaving that aside, is your code based on a single thread or multi-thread?

Many thanks :-)

PS I'm guessing single thread
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi Andy,

I can see your point. Yes in part this is learning. But trying to get my head around the concepts. Fair enough that you say messy but I don't know enough to know that. I see a situation where I feel i should reuse a tool but don't yet understand why it is ok to recreate the userform over and over (when other code is modular).

Hope this makes sense.

Cheers
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi All - thank you for all this information.  It feels like things are starting to gel...

Saige - that's a great example, gives me a lot of insight that I might have taken a while longer to stumble upon; thanks.

Andy - it seems that your comment here reflects exactly what I was setting out to achieve:
A dll is a library of common code.  It might just number crunch, it might contain forms.  Nice and modular.  It can be reused in many places in your app, or even other apps.

A progress bar is an informative way to show progress to the user.  Part of the GUI - specific to an app.
To put things in perspective I have a fairly extensive set of macros in VBA which ultimately will be rewritten in C#;  to this end I have the help of a programmer.  However, I recently faced a problem that (as far as I could tell) VBA simply unable to deal with - I struggled with VB.Net and eventually used an online code converter to to generate C#.Net from my VB.Net code and finally resolved my problem.

The syntax of VB.Net was pretty easy for me because of my VBA experience, but C# is, well, different.  

I mention this because what I have now is a large chunk of VBA 30k lines and a small chunk of C# dll that I use from VBA by declaring the function:
Private Declare Function myFunction lib "myFirstDLL.dll"....

Open in new window

So, reflecting further on your statement
A progress bar is an informative way to show progress to the user.  Part of the GUI - specific to an app.
yes that makes perfect sense to me... BUT how?!

Given the background of my project, what should I do?  Build the ProgressBar in VBA and pause my dll for a short time in each loop so my VBA GUI can update?  Is there a clear way forward?  

Right now the answer seems to be the progress bar is (should be) app specific and part of the GUI, but then your next statement makes this very pursuit seem impractical:
To reuse the progress bar it implies you would somehow need to instruct the function which time intensive procedure in which dll would need to be called AND how that will communicate back (without mentioning cross-threading of GUI elements).
I feel like I'm missing something quite fundamental - if the progress bar is part of the GUI then surely it is meant to be reused?
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi Andy -

I think I must have misunderstood what you were driving at.  It seemed like you were saying the app specific progress bar could (/ should?) report progress for operations that might be done in some dll somewhere, and that dll could be used by other apps...

What I was getting at with my question:
>>if the progress bar is part of the GUI then surely it is meant to be reused?
was if (for want of a better expression) I 'subcontract' work out to a dll that just happens to be so useful that many of my applications use it (I'm dreaming now) then how should I report the progress that my dll is making if I feel the need to present this to the end user?
BTW - right now, this really is not an issue.  I am more than happy to modify the dll to include a userform with a progress bar.  I'm just wondering which approach is the most conventional ;-)  

Here to learn!
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi,

Thanks for your comments - unfortunately my attention has been dragged away from this. I'm keen to resume but it will be at least a week before I have the opportunity.

I'm still missing something fundamental - I guess that's what happens when you try to learn programming informally 😣😮
Hi Guys,

Thanks for your thoughts and helping me to better understand how this hangs together.  I've not had a chance to revisit this properly but hope to soon.  Appreciate your time, each comment helped.

Cheers,