When you're not using VS and open the page in the IE, a loop keeps executing
even if you close IE, right? And as checking the Response.IsClientConnected
can avoid that, and I'm supposing that the same behavior is happening when
you debug thru VS.
Then maybe the solution is the same.
I think that the big question you should answer is: What I want to do in my
application when the user closes the browser during the loop? Should it stop
processing?
If so, the Response.IsClientConnected will solve both issues (debug and
runtime).
"Chip" <ch**@intradata.com> wrote in message
news:Oa**************@TK2MSFTNGP14.phx.gbl...
I'm stopping the process within the VS 2003 dev environment.by pressing
the STOP button. Your advice sounds good, but should VS be stopping the
process when it's told to?
"Mateus Padovani Velloso" <ma****@flag.com.br> wrote in message
news:Oe*************@TK2MSFTNGP14.phx.gbl... How do you stop the process?
You should use Response.IsClientConnected to see if the browser stills
there, and in case of false, abort the thread.
"Chip" <ch**@intradata.com> wrote in message
news:e3*************@TK2MSFTNGP15.phx.gbl... Can somebody explain to me why my process continues to run after I halt
execution? This plays havoc with debugging. I expect to be starting a
new instance at the beginning of a loop and the first break point hit is
thousands of itterations into the process (from a previous instance). I
get a very random step behavior. Know I am watching a database continue
to be updated 10 minutes after I stopped the front-end process. I have
to stop IIS to halt execution.
Chip