Gee - in a desktop application, you would probably use threading, but you
really can't safely do asynchronous programming in web applications, in my
opinion.
I think if I were you, I would look at the architecture, rather than the
cosmetics of a long operation. What can you do so that the user isn't held
up on the page? What if you encapsulate the processing functionality in a
component that can be triggered via an MSMQ message? Then you don't need to
keep the user waiting, and the long processing work is put behind the scenes
to process in its own due course (really this is asynchronous programming,
just without threading.)
If the long operation results in data displayed to the screen, one trick you
can do is to put the processing function in a second page. Put the call to
the processing functionality somewhere in the rendered html, so that the
processing only starts after something displays to the user indicating work
in process.
Something like this.
<%# Page Language=C# %>
<script runat=server>
private void DoSomeBigThing()
{
//lots of hard stuff
}
</script>
<html>
<head/>
<body>
<p>Working...</p>
<% DoSomeBigThing(); %>
<p> etc....</p>
</body>
</html>
"Luiz Vianna" <lv*****@multconnect.com.br> wrote in message
news:ux**************@TK2MSFTNGP09.phx.gbl...
Hi folks,
I got a problem that certainly someone had too.
After a user request, I (my server) must process a lot of data that will
expend some time. During this process I must inform the user the status of
the overall process.
What I'm facing is that my ASPX/vb file that does this long task is
completely processed before some response could be given to the user.
Result: After filling the form, the user clicks the button and the form
remains on the screen while processing time and the user is not sure that
the process is running or even if it was fired.
I've tried some ideas like
- using response.write/response.flush
- Using server.transfer/server.execute
but they didn't work. Someone have some good idea????
Thanks in advance
Luiz
