dotnet windows forms: We have a window appliccation, which is written in .C# (.net 2003).

One of the feature of this application is to allow users to download
data from our repository database (Oracle) and then display the data.
The "download" dialog is simple: a window form with a progress bar and
a cancel button. The dialog closes itself when download is completed.

Our problem is: when data download starts, if a user click on the
cancel button, it does not response. The break point inside the
button_click event menthos is never reached. That also happens even
when I stop the progress bar update.

If I just open the dialog without downloading any data (comment out
downloading code), the cancel button responses correctly. I was able
to make break points in all event methods and test them.

Data downloading only take about 10% of my CPU process.

How do I fix this problem?

Thanks in advance.

On 07/01/2008 in message
<4f4c7678-247f-40f1-8ec1-4ee2b277a01a@i72g2000hsd.googlegroups.com>
[quoted text, click to view]

I had this with an FTP client I am writing. I added an
'Application.DoEvents()' in the down-load loop. You could then use a
boolean 'abort' variable, set it when Cancel is clicked and check for it
in the down-load loop.

--

I'm assuming that the download is happening on the UI thread; this
means that the UI cannot respond to any inputs. You should investigate
the BackgroundWorker component (lots of examples around), which will
push this work to a background thread, while still making it easy (via
the progress changed event) to update your progress-bar. Most
importantly, the UI thread will be able to service the cancel button,
and ask the BackgroundWorker to cancel (your code needs to check for
this cancellation request periodically).

Marc

[quoted text, click to view]
Just for purism... Application.DoEvents() isn't always a
good/recommended solution to this problem - you can run into all sorts
of issues with reentrancy, and other odd "trying to do 2 things on 1
thread" issues, etc. If it was me, I'd *absolutely* be using a worker
thread here.

[quoted text, click to view]
As a second note on the abort variable - if you went this route, you'd
probably want to make this field "volatile", otherwise it gets a bit
hit-and-miss on whether your loop will ever see the change (it could
perhaps be help on a register).

Marc