The checking should be inside the loop where you are iterating. Your code
seems to be OK.
I suggest you should first try some simple testings on both development and
production machines.
Following is a test code for your.
1. private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e
)
2. {
3. BackgroundWorker b = (BackgroundWorker)sender;
4. for (int i = 0; i < 5; i++)
5. {
6. DateTime d = DateTime.Now;
7. // wait for 2 seconds simulating a long operation
8. while (((TimeSpan)DateTime.Now.Subtract(d)).Seconds <
2) ;
9. // update count in textbox
10. this.updatecount(i);
11. // if cancel request is pending
12. if (b.CancellationPending) {
13. e.Cancel = true;
14. break;
15. }
16. }
17. }
18.
19. private delegate void updatecountdelegate(int i);
20. private void updatecount(int i)
21. {
22. if (this.textBox1.InvokeRequired)
23.
this.textBox1.Invoke(new<http://www.google.com/search?q=new+msdn.microsoft.com>
updatecountdelegate(updatecount), i);
24. else
25. this.textBox1.Text = i.ToString();
26.
27. }
28.
29. private void BW_Complete(object sender,
RunWorkerCompletedEventArgs e)
30. {
31. MessageBox.Show("Operation" + (e.Cancelled ? " was
cancelled" : " completed successfully"));
32. this.btnStart.Enabled = true;
33. }
34.
35. private void btnStart_Click(object sender, EventArgs e)
36. {
37. this.btnStart.Enabled = false;
38. this.btnStop.Enabled = true;
39. this.backgroundWorker1.RunWorkerAsync();
40. }
41.
42. private void btnStop_Click(object sender, EventArgs e)
43. {
44. this.btnStop.Enabled = false;
45. this.backgroundWorker1.CancelAsync();
46. }
On Fri, Oct 16, 2009 at 2:36 PM, Benj Nunez <[email protected]> wrote:
>
> Hello Arsalan,
>
>
> I looked into my code again and confirmed that the CancellationPending
> property
> has already been implemented. Still no go. :(
>
> Originally the call to CancellationPending is within a foreach loop
> like this:
>
>
> public bool parseEntries(ref BackgroundWorker worker,
> ref List<StringHolder> ACVMEntries,
> ref DoWorkEventArgs e)
> {
> ...
> if (ACVMEntries != null)
> {
> ..
> foreach (StringHolder shEntry in ACVMEntries)
> {
> ...
> if (worker.CancellationPending)
> {
> e.Cancel = true;
> //return false;
> break;
> }
>
> // long work starts here...
> }
> }
>
> }
>
>
> I changed it and tried calling the property *before* the loop like
> this:
>
>
> public bool parseEntries(ref BackgroundWorker worker,
> ref List<StringHolder> ACVMEntries,
> ref DoWorkEventArgs e)
> {
> ...
> if (worker.CancellationPending)
> {
> e.Cancel = true;
> //return false;
> break;
> }
> else
> {
> if (ACVMEntries != null)
> {
> ..
> foreach (StringHolder shEntry in ACVMEntries)
> {
> ...
> // long work starts here...
> } // of foreach
>
> } // of inner if
>
> } // of outer if
>
> }
>
>
> Any help appreciated.
>
>
>
> Benj
>
>
>
>
> On Oct 14, 11:27 am, Benj Nunez <[email protected]> wrote:
> > Hello Arsalan,
> >
> > I will re-write the code under my worker thread to see if
> > CancellationPending will
> > work. This I think, must be it.
> >
> > Thank you,
> >
> > Benj
> >
> > On Oct 13, 6:37 pm, Arsalan Tamiz <[email protected]> wrote:
> >
> > > Andrew is right that you haven't provided any details. But I would like
> to
> > > put some points for you,
> >
> > > According to MSDN,
> > > -----------------
> >
> > > CancelAsync submits a request to terminate the pending background
> operation
> > > and
> >
> > > "sets the CancellationPending<
> http://msdn.microsoft.com/en-us/library/system.componentmodel.backgro...>
> > > property
> > > to true."
> >
> > > When you call CancelAsync, your worker method has an opportunity to
> stop its
> > > execution and exit.
> >
> > > "The worker code should periodically check the
> > > CancellationPending<
> http://msdn.microsoft.com/en-us/library/system.componentmodel.backgro...>
> > > property
> > > to see if it has been set to true."
> >
> > > -----------------
> > > So its your responsibility to check the "CancellationPending" property.
> Are
> > > you checking it? If you are checking then see what statements are being
> > > executed before this "checking". Are those statements being hanged
> > > somewhere?
> >
> > > Regards,
> > > Arsalan Tamiz
> >
> > > On Tue, Oct 13, 2009 at 12:20 PM, Benj Nunez <[email protected]>
> wrote:
> >
> > > > Hello everyone,
> >
> > > > I recently wrote a program that allows users to interrupt a process
> > > > which runs within a thread.
> > > > I have code that looks like this:
> >
> > > > private void btnStop_Click(object sender, EventArgs e)
> > > > {
> > > > bwOverAll.CancelAsync();
> > > > btnStop.Enabled = false;
> > > > }
> >
> > > > I'm not sure if threads rely somewhat on what CPU the PC has. I have
> > > > tested my program to run
> > > > on the following PCs and I can start/stop threads at will with no
> > > > issues:
> >
> > > > PC#1) Windows XP Home with SP3. Intel Pentium D 2.80Ghz, 504mb ram,
> > > > Hyperthreading enabled.
> > > > PC#2) Windows XP Pro with SP3, Intel Pentium 4, 2GB ram,
> > > > Hyperthreading enabled.
> >
> > > > On the production machine however, I checked its specifications to be
> > > > like this:
> >
> > > > PC#3) Windows XP Home, Intel Celeron.
> >
> > > > All three PCs have .net framework 3.5 installed.
> >
> > > > That's all I can remember. But I can check again about its ram and
> > > > clock speed.
> > > > Could you tell me exactly where to first look for in cases like this?
> > > > Normally I expect that
> > > > when I click the button to stop an action (threaded), there's a brief
> > > > delay then the thread eventually stops. But in my case it didn't.
> >
> > > > Any advice?
> >
> > > > Benj
