no response for cancel button click

  • Thread starter Thread starter linda.chen
  • Start date Start date
L

linda.chen

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.

Linda
 
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
 
On 07/01/2008 in message
<4f4c7678-247f-40f1-8ec1-4ee2b277a01a@i72g2000hsd.googlegroups.com>
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.

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 added an 'Application.DoEvents()' in the down-load loop.
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.
You could then use a boolean 'abort' variable
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
 
Back
Top