Visual Basic - Question on program design

Author

Question on program design - progress reporting

Nomospam

2005-08-28, 9:55 pm

example problem

I have a small program that does four step process. Each step may call
various subs/functions or forms

The whole process may take several seconds or more. I want to display a
progress report while it's running

wondering what is the best way to get a running report of activity so it
doesn't look like the prog just stopped running (while it's doing calcs or
whatever)

I'm thinking of the idea of de-coupling and thinking to make a class
ProgressReport as an object

and that object will have the responsibility to report on each subs progress
as desired.

That way implementation could change over time as needs/knowlege changed.

At this point I'm wanting to start with a form with a label

I want to show that form (i think modeless? so it can sit around while the
program is running

and give intermittent messages to user so they can see it's working on their
request.

Should I pass the report object into each sub/function as an optional byref
param?

Or should it be somehow global so every sub/function can call it's methods
without having

to receive the object as an argument?

Or is there some other better way?

example:

'pass in as param

Function PhaseOne(arg1, arg2, Optional ByRef oReport as Object)

oReport.CurrentAction = "Calculating values"

CalculateValues(arg1, arg2)

oReport.CurrentAction = "Done Calculating values"

end Function

example:

global object somehow?

Function PhaseOne(arg1, arg2)

oReport.CurrentAction = "Calculating values"

CalculateValues(arg1, arg2)

oReport.CurrentAction = "Done Calculating values"

end Function

'are there general reasons to do one or the other?

I'm not sure where the report object should be defined so every function in
std modules and in

other forms can see the report object and use it to display the current
state of the program

execution.

however it's done, do i need DoEvents in subs for the reportobject to be
updated?

my first try seemed to indicate that the reportform was shown but the labels
didn't update

as the subs ran in the background.

any guidance appreciated

Thanks

Mark

J French

2005-08-29, 3:55 am

On Sun, 28 Aug 2005 21:53:32 -0500, "Nomospam" <Nomospam@Nomospam.com>
wrote:

>example problem
>
>I have a small program that does four step process. Each step may call
>various subs/functions or forms
>
>The whole process may take several seconds or more. I want to display a
>progress report while it's running
>
>wondering what is the best way to get a running report of activity so it
>doesn't look like the prog just stopped running (while it's doing calcs or
>whatever)
>
>I'm thinking of the idea of de-coupling and thinking to make a class
>ProgressReport as an object

<snip>

Personally I would put all the 'process intensive' code in a Class
- then Dim it WithEvents in a parent Form

- the child class can then use RaiseEvent to pass messages back to its
parent
- if necessary the 'process intensive' code could be in a number of
Classes that RaiseEvent into the controlling Class, and that does
RaiseEvent back up to the Parent.

The advantage of this is that the 'process intensive' code knows
nothing about its Parent

It also leads towards a neat hierarchical design, and allows one to
avoid Globals and multiple references to Objects.

Larry Serflaten

2005-08-29, 7:55 am

"Nomospam" <Nomospam@Nomospam.com> wrote

> Should I pass the report object into each sub/function as an optional byref
> param?
>
> Or should it be somehow global so every sub/function can call it's methods
> without having to receive the object as an argument?

If your progress indicator is a separate form, it will already be scoped globally.

> 'are there general reasons to do one or the other?

Either way you'd be tied to using some specific object:

> Function PhaseOne(arg1, arg2, Optional ByRef oReport as Object)
> oReport.CurrentAction = "Calculating values"

Function will be dependant on oReport having a CurrentAction method

> Function PhaseOne(arg1, arg2)
> oReport.CurrentAction = "Calculating values"

Function will be dependant on oReport being available.

> however it's done, do i need DoEvents in subs for the reportobject to be
> updated?
>
> my first try seemed to indicate that the reportform was shown but the labels
> didn't update

Use the control's Refresh method to get them to show newly added text.

> any guidance appreciated

Do you really need to send reports from within nested routines? Could it
be possible to write your steps such that they return error/sucess codes
so that you can call them all from one place and report back when they return?

As J French indicated, raising events from a class would assist you in
decoupling the process intensive code from any other object that wants to
listen for reports....

LFS

2005-08-29, 6:55 pm

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:eANp0OJrFHA.3216@TK2MSFTNGP12.phx.gbl...
>
> "Nomospam" <Nomospam@Nomospam.com> wrote
>

> Do you really need to send reports from within nested routines? Could it
> be possible to write your steps such that they return error/sucess codes
> so that you can call them all from one place and report back when they
return?
>
> As J French indicated, raising events from a class would assist you in
> decoupling the process intensive code from any other object that wants to
> listen for reports....
>
> LFS

Thank you both for your insights.
I will study and contemplate
mark

Ralph

2005-08-29, 6:55 pm

"Nomospam" <Nomospam@Nomospam.com> wrote in message
news:431278d1$0$7631$8b463f8a@news.nationwide.net...
> example problem
>
> I have a small program that does four step process. Each step may call
> various subs/functions or forms
>
> The whole process may take several seconds or more. I want to display a
> progress report while it's running
>
> wondering what is the best way to get a running report of activity so it
> doesn't look like the prog just stopped running (while it's doing calcs or
> whatever)
>
> I'm thinking of the idea of de-coupling and thinking to make a class
> ProgressReport as an object
>
> and that object will have the responsibility to report on each subs
progress
> as desired.
>
> That way implementation could change over time as needs/knowlege changed.
>
> At this point I'm wanting to start with a form with a label
>
> I want to show that form (i think modeless? so it can sit around while the
> program is running
>
> and give intermittent messages to user so they can see it's working on
their
> request.
>
> Should I pass the report object into each sub/function as an optional
byref
> param?
>
> Or should it be somehow global so every sub/function can call it's methods
> without having
>
> to receive the object as an argument?
>
>
> Or is there some other better way?
>
> example:
>
> 'pass in as param
>
> Function PhaseOne(arg1, arg2, Optional ByRef oReport as Object)
>
> oReport.CurrentAction = "Calculating values"
>
> CalculateValues(arg1, arg2)
>
> oReport.CurrentAction = "Done Calculating values"
>
> end Function
>
> example:
>
> global object somehow?
>
> Function PhaseOne(arg1, arg2)
>
> oReport.CurrentAction = "Calculating values"
>
> CalculateValues(arg1, arg2)
>
> oReport.CurrentAction = "Done Calculating values"
>
> end Function
>
> 'are there general reasons to do one or the other?
>
> I'm not sure where the report object should be defined so every function
in
> std modules and in
>
> other forms can see the report object and use it to display the current
> state of the program
>
> execution.
>
> however it's done, do i need DoEvents in subs for the reportobject to be
> updated?
>
> my first try seemed to indicate that the reportform was shown but the
labels
> didn't update
>
> as the subs ran in the background.
>
> any guidance appreciated
>
> Thanks
>
> Mark
>

To expand on Mr. French's recommendation, you can create a single "Event
Class" and then pass a reference to that class to all parties that may have
something interesting to report.

-ralph

2005-08-29, 6:55 pm

Xref: TK2MSFTNGP08.phx.gbl microsoft.public.vb.general.discussion:563044

"J French" <erewhon@nowhere.uk> wrote in message
news:4312c3bb.2380074@news.btopenworld.com...
> On Sun, 28 Aug 2005 21:53:32 -0500, "Nomospam" <Nomospam@Nomospam.com>
> wrote:
>

<snip>
[color=darkred]
> Personally I would put all the 'process intensive' code in a Class
> - then Dim it WithEvents in a parent Form
>
> - the child class can then use RaiseEvent to pass messages back to its
> parent
> - if necessary the 'process intensive' code could be in a number of
> Classes that RaiseEvent into the controlling Class, and that does
> RaiseEvent back up to the Parent.
>
> The advantage of this is that the 'process intensive' code knows
> nothing about its Parent
>
> It also leads towards a neat hierarchical design, and allows one to
> avoid Globals and multiple references to Objects.
>

Thanks, that sounds like the direction i want to head.
Now to study up on events
I'll post back if i figure it out to see if I got it right.
Thanks,
Mark

2005-08-29, 6:55 pm

"Ralph" <nt_consulting64@yahoo.com> wrote in message
news:zd6dnf6HKu4plI7eRVn-og@arkansas.net...
>
> "Nomospam" <Nomospam@Nomospam.com> wrote in message
> news:431278d1$0$7631$8b463f8a@news.nationwide.net...
[color=darkred]
> To expand on Mr. French's recommendation, you can create a single "Event
> Class" and then pass a reference to that class to all parties that may
have
> something interesting to report.
>
> -ralph
>
>

Thanks
That sounds like the approach I was looking for.
I need to re-study my notes on events to figure out the details.
Thanks,
Mark

Sponsored Links