SmtpMail.send() does _not_ cause button click to block . . .

Hi,

I am using a simple form to test a library I am developing. The library
reads data from a database, puts together a report, and then sends the
report to a number of email recipients. I am initiating this process by
clicking a button on the form.

The smtp server I'm working with is a bit sluggish, so the
SmtpMail.Send() is taking about 5-10 seconds to return (don't ask; this
is out of my control). Stepping through the code in the debugger,
something a bit odd happens: it appears as if Send()returns
immediately, and the form pops back up, without any of the code
following Send() being executed. I wait the amount of time I know that
Send() really takes, and then the debugger pops back into the code at
the line just following Send(). I do not see this behavior if I drive
the library from a console app: here, the blocking behavior of Send()
causes the debugger to sit and wait until Send() returns, as one would
expect.

What's going on here? It almost seems as if the Application is deciding
that the execution of Send() is taking too long and somehow putting it
into the background. I don't understand how that could be happening
given that I never created a new thread for it to execute. Moreover, it
seems to me that this behavior could cause major problems upon
re-entry. For example: the GUI becomes active, and so I click the test
button again, and it ends up re-running code that is not intended to be
thread safe; what if I'm in the middle of re-running that code when
Send() does return?

In production, this library will be driven from from a windows service
application. Might the difference between exercising this code through
a GUI, versus through a command-line app, be the presence a message
loop? If so, then this problem remains relevant in the service
application, and I need to figure out what to do.

Can this behavior be controlled, or do I have to run SmtpMail.Send() in
its own thread in order to head this problem off?

Thanks.

--Phil

.