Maybe I'm overly optimistic, but I'd think that anyone using BWT would have done a little basic research and reading and would understand the model ... otherwise, what would make an uninformed someone use BWT over Thread? It doesn't exactly jump off the tip of the tongue.
∞ Andy Badera ∞ +1 518-641-1280 ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me: http://www.google.com/search?q=andrew%20badera On Tue, Oct 13, 2009 at 6:45 AM, Arsalan Tamiz <[email protected]> wrote: > Can't say for sure. I am assuming he is using backgroundworker control > because he used "bwOverAll" > bw = Background Worker > ? > > On Tue, Oct 13, 2009 at 4:41 PM, Andrew Badera <[email protected]> wrote: >> >> Arsalan, >> >> That's for BTW. The OP didn't specify BTW, I bet he's using classic >> Thread. >> >> ∞ Andy Badera >> ∞ +1 518-641-1280 >> ∞ This email is: [ ] bloggable [x] ask first [ ] private >> ∞ Google me: http://www.google.com/search?q=andrew%20badera >> >> >> >> On Tue, Oct 13, 2009 at 6:37 AM, 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 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 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 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> > > >
