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
