Thanks for all the feedback.
Decoupling - I guess thats the word for it - the datagrid from the
main thread and filling a separate string array or arraylist to pass
to a separate email class did the trick. I cannot wait in my asp.net
page codebehind to wait for a thread.join. My only remaining query is
there anything I should do in the separate email class to close the
thread, I assume garbage collection will take care of this
anyhow....Also maybe I could start the thread in the separate email
class..
here is current code sample...
private void MultipleAttachEmail_Click(object sender, System.EventArgs
e)
{
foreach(DataGridItem dgi in documentDataGrid.Items)
{
attachments.Add(Server.MapPath(baseURL + dgi.Cells[2].Text));
}
DocumentsEmail dem = new
DocumentsEmail(attachments,EmailAddress.Text);
ThreadStart ts = new ThreadStart(dem.SendMultipleAttachEmail);
thread = new System.Threading.Thread(ts);
thread.Start();
Session["BasketSession"] = null;
Response.Redirect("DocBasketCheckout.aspx?%^="+Ema ilAddress.Text);
}
the new DocumentsEmail class
using System;
using System.Collections;
using System.Threading;
using System.Web.Mail;
using System.Web;
namespace Org.Web.UI
{
public class DocumentsEmail
{
private ArrayList _intArrList;
private string _email;
public DocumentsEmail(ArrayList inArrList, string inEmail)
{
_intArrList = inArrList;
_email = inEmail;
}
public void SendMultipleAttachEmail()
{
MailMessage msgMail = new MailMessage();
msgMail.To = _email;
msgMail.From = "Org Website" + " <we*****@org.co.uk>";
msgMail.Subject = "Your Documents";
msgMail.BodyFormat = MailFormat.Text;
msgMail.Body = " ";
// Gets document location path from Document Basket.
foreach(string dgi in _intArrList)
{
msgMail.Attachments.Add(new MailAttachment(dgi));
}
SmtpMail.SmtpServer = "192.168.0.253";
SmtpMail.Send(msgMail);
}
}
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message news:<#z**************@TK2MSFTNGP12.phx.gbl>...
well as rick pointed out, the other issue is that by the time the thread is
finished, the page is gone. I've seen others put a sleep in the main page or
a join to force the main thread to wait on the child thread to execute.
Infact, i've used the join which seems to work well.
Even in OP's case, the thread is still touching the response object which is
a main thread object.
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/27cok
"Sharon" <ta*******@hotmail.com> wrote in message
news:eC**************@TK2MSFTNGP10.phx.gbl... maybe this way will work:
aspx page
=========
<%@ Page Language="cs" %>
<%@ import namespace="System.Threading" %>
<%@ import namespace="test" %>
<%
string[] passArr = new string[2]{"arr val 1", "arr val 2"};
ThreadProc tp = new ThreadProc(passArr);
Thread t = new Thread(new ThreadStart(tp.ThreadProcStart));
t.Start();
%>
<html>
<head>
</head>
<body>
</body>
</html>
thread class
==========
using System.Threading;
using System.IO;
namespace test
{
public class ThreadProc
{
private string[] m_dispStrArr;
public ThreadProc(string[] inStrArr) {
m_dispStrArr = inStrArr;
}
public void ThreadProcStart() {
for (int i = 0; i < 20; i++)
{
StreamWriter fsw =
File.AppendText(System.AppDomain.CurrentDomain.Bas eDirectory +
"\\log.txt");
fsw.WriteLine("m_dispStr: " + m_dispStrArr[0] + " " + m_dispStrArr[1]
+ " i: " + i);
fsw.Close();
fsw = null;
Thread.Sleep(1000);
}
}
}
}
it works but, maybe you can find a flaw?
"Rick Strahl [MVP]" <ri********@hotmail.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl... Hi Alvin,
You're right of course and that's sort of what I was getting at <g>...
In this case though I'm certain that the problem is that hte page is gone by the time the thread fires up. Matt does a Redirect() immediately
following
the Thread creation which exits the page and recylces the thread. This is
likely to happen way before the new thread even starts. So if there's any
reliance on anything from the ASP page it's not likely to be there.
I've run into this in a few of my own applications and it's really a
bitch
to catch if you don't know this is happening because in most cases you don't get a failure in teh ASP.Net page because *it* completed fine. The exception happens on another thread unknown to the ASP.Net runtime and thus you get no messages. The thread falls down and goes away and you get an eventlog entry for this, but otherwise nothing.
In general I would say this is a bad idea unless you always force your state to the thread object itself and/or you call fully selfcontained static code.
Another possibly better alternative is to use Asynchronous Requests...
+++ Rick ---
