break in batch testing...

[guy]

Hi,

I'm running a batch test using a C# program. This often takes several hours
to run and iterates over a bunch of parameters (say) 1000 times.

The processor is maxed out during this time.

I'd like to provide a button that cancels the batch test when it is
partially done.

I'm thinking about putting some Wait() or Pause() code in between the
iterations and then setting a flag if a Cancel button is pushed but not sure
if this would work.

What is the standard approach to implementing this sort of thing?

Thanks

[Robert Jordan]

Hi,

Hi,

I'm running a batch test using a C# program. This often takes several hours
to run and iterates over a bunch of parameters (say) 1000 times.

The processor is maxed out during this time.

I'd like to provide a button that cancels the batch test when it is
partially done.

I'm thinking about putting some Wait() or Pause() code in between the
iterations and then setting a flag if a Cancel button is pushed but not sure
if this would work.

What is the standard approach to implementing this sort of thing?

Disable all UI controls but the cancel button. Call
Application.DoE vents() between the iterations, say ever x
iterations.

bye
Rob

[Jon Skeet [C# MVP]]

Robert Jordan <ro*****@gmx.ne t> wrote:

I'm running a batch test using a C# program. This often takes several hours
to run and iterates over a bunch of parameters (say) 1000 times.

The processor is maxed out during this time.

I'd like to provide a button that cancels the batch test when it is
partially done.

I'm thinking about putting some Wait() or Pause() code in between the
iterations and then setting a flag if a Cancel button is pushed but not sure
if this would work.

What is the standard approach to implementing this sort of thing?

Disable all UI controls but the cancel button. Call
Application.DoE vents() between the iterations, say ever x
iterations.

I disagree with this, apart from disabling all UI controls. It is
better to run the iterations on a separate thread and test for a flag.
Application.DoE vents() can cause nastiness like re-entrancy. To my
mind, Application.DoE vents() is basically a throw-back to VB not having
"proper" threading for a long time, and should be avoided in almost all
situations.

UIs should be kept responsive by keeping their message pump threads
idle for as much of the time as possible.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[guy]

Hi Jon and Robert,

Thanks for the replies. I tried using the Application.DoE vents() suggested
by Robert but not the disable UI and it works a treat.

Jon, could you elaborate on not using this.

I'm basically popping up a "progress" dialog which reports time elapsed and
% progress through the batch test etc. and there is a Cancel button on this
dialog. The main code that popped up this progress dialog checks a flag in
this class and if set stops the batch testing. This flag is set by clicking
the Cancel button. I find that if I don't inlcude the .DoEvents() call in
the check to the flag then clicking on the Cancel button does not set the
flag...

Thanks
"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Robert Jordan <ro*****@gmx.ne t> wrote:

> I'm running a batch test using a C# program. This often takes several
> hours
> to run and iterates over a bunch of parameters (say) 1000 times.
>
> The processor is maxed out during this time.
>
> I'd like to provide a button that cancels the batch test when it is
> partially done.
>
> I'm thinking about putting some Wait() or Pause() code in between the
> iterations and then setting a flag if a Cancel button is pushed but not
> sure
> if this would work.
>
> What is the standard approach to implementing this sort of thing?

Disable all UI controls but the cancel button. Call
Application.DoE vents() between the iterations, say ever x
iterations.

I disagree with this, apart from disabling all UI controls. It is
better to run the iterations on a separate thread and test for a flag.
Application.DoE vents() can cause nastiness like re-entrancy. To my
mind, Application.DoE vents() is basically a throw-back to VB not having
"proper" threading for a long time, and should be avoided in almost all
situations.

UIs should be kept responsive by keeping their message pump threads
idle for as much of the time as possible.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Robert Jordan]

Hi Jon,

Robert Jordan <ro*****@gmx.ne t> wrote:

I'm running a batch test using a C# program. This often takes several hours
to run and iterates over a bunch of parameters (say) 1000 times.

The processor is maxed out during this time.

I'd like to provide a button that cancels the batch test when it is
partially done.

I'm thinking about putting some Wait() or Pause() code in between the
iterations and then setting a flag if a Cancel button is pushed but not sure
if this would work.

What is the standard approach to implementing this sort of thing?
Disable all UI controls but the cancel button. Call
Application.D oEvents() between the iterations, say ever x
iterations.

I disagree with this, apart from disabling all UI controls. It is
better to run the iterations on a separate thread and test for a flag.
Application.DoE vents() can cause nastiness like re-entrancy. To my
mind, Application.DoE vents() is basically a throw-back to VB not having
"proper" threading for a long time, and should be avoided in almost all
situations.

UIs should be kept responsive by keeping their message pump threads
idle for as much of the time as possible.

Well, it depends on the target "audience" of the application.
I read:
I'm running a batch test using a C# program. This often takes several
hours to run and iterates over a bunch of parameters (say) 1000 times.

The main purpose of the app appears to be the batch job and not
a fancy and responsible UI. That's the reason why I recommended
Application.DoE vents().

My mistake was not to mention the threading solution at all.

Thanks
Rob

[Jon Skeet [C# MVP]]

guy <wi*********@ho tmail.com> wrote:

Thanks for the replies. I tried using the Application.DoE vents() suggested
by Robert but not the disable UI and it works a treat.

Jon, could you elaborate on not using this.

I'm basically popping up a "progress" dialog which reports time elapsed and
% progress through the batch test etc. and there is a Cancel button on this
dialog. The main code that popped up this progress dialog checks a flag in
this class and if set stops the batch testing. This flag is set by clicking
the Cancel button. I find that if I don't inlcude the .DoEvents() call in
the check to the flag then clicking on the Cancel button does not set the
flag...

Sure - because presumably you're doing all your processing on the UI
thread, which is a bad idea to start with.

I suggest you read my tutorial on threads:

http://www.pobox.com/~skeet/csharp/threads/

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Robert Jordan <ro*****@gmx.ne t> wrote:

UIs should be kept responsive by keeping their message pump threads
idle for as much of the time as possible.

Well, it depends on the target "audience" of the application.
I read:

> I'm running a batch test using a C# program. This often takes several
> hours to run and iterates over a bunch of parameters (say) 1000 times.

The main purpose of the app appears to be the batch job and not
a fancy and responsible UI. That's the reason why I recommended
Application.DoE vents().

My mistake was not to mention the threading solution at all.

While I agree that a UI for batch processing doesn't need to be fancy,
I disagree about responsible. A UI which is written properly to start
with can easily be extended to provide more feedback etc. No guesswork
is required as to when to call DoEvents. Also, learning just one way of
"doing it right" as regards long-running tasks and UIs is better (IMO)
than learning the "quick and dirty" way and then later learning the
"proper" way (using worker threads).

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Robert Jordan]

Hi Jon,

The main purpose of the app appears to be the batch job and not
a fancy and responsible UI. That's the reason why I recommended
Application.D oEvents().

My mistake was not to mention the threading solution at all.

While I agree that a UI for batch processing doesn't need to be fancy,
I disagree about responsible. A UI which is written properly to start
with can easily be extended to provide more feedback etc. No guesswork
is required as to when to call DoEvents. Also, learning just one way of
"doing it right" as regards long-running tasks and UIs is better (IMO)
than learning the "quick and dirty" way and then later learning the
"proper" way (using worker threads).

If one recommends threading in conjuction with UI, then it's just
a matter of time until the next question about async UI access problems
will be placed, if ever detected and recognized as such.
As you know, that kind of problem can be much subtle then DoEvents.

So what's the best approach to teach that in a newsgroup?
A full blown monologue about Control.Invoke or ignoring it
at all?

Thanks
Rob

[Jon Skeet [C# MVP]]

Robert Jordan <ro*****@gmx.ne t> wrote:

While I agree that a UI for batch processing doesn't need to be fancy,
I disagree about responsible. A UI which is written properly to start
with can easily be extended to provide more feedback etc. No guesswork
is required as to when to call DoEvents. Also, learning just one way of
"doing it right" as regards long-running tasks and UIs is better (IMO)
than learning the "quick and dirty" way and then later learning the
"proper" way (using worker threads).
If one recommends threading in conjuction with UI, then it's just
a matter of time until the next question about async UI access problems
will be placed, if ever detected and recognized as such.
As you know, that kind of problem can be much subtle then DoEvents.

"More subtle" is a tough one to call - both are incredibly nasty if
they don't crop up regularly, but I find the ones due to async calling
are easier to avoid when you know about them.

(Fortunately Avalon is going to make things much simpler - if you call
something on the wrong thread, you'll get an exception immediately.)
So what's the best approach to teach that in a newsgroup?
A full blown monologue about Control.Invoke or ignoring it
at all?

Certainly don't ignore it - I point people to my article on threading,
written precisely for the purpose of not having to write the same thing
in several posts :)

http://www.pobox.com/~skeet/csharp/threads

and for Windows Forms programming in particular
http://www.pobox.com/~skeet/csharp/t...winforms.shtml

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Robert Jordan]

Hi Jon,

So what's the best approach to teach that in a newsgroup?
A full blown monologue about Control.Invoke or ignoring it
at all?

Certainly don't ignore it - I point people to my article on threading,
written precisely for the purpose of not having to write the same thing
in several posts :)

http://www.pobox.com/~skeet/csharp/threads

and for Windows Forms programming in particular
http://www.pobox.com/~skeet/csharp/t...winforms.shtml

Thanks a lot!
Rob