09. oktober 2007 - 20:49Der er
7 kommentarer og 1 løsning
System.Threading.ThreadAbortException igen ved screen export
Jeg strikker på noget til direkte at lave en csv fil ud af et gridview. Har ingen problemer med at skabe/hente data (selv om det ikke er vist i mit eskempel her), og koden fungerer såmænd godt nok.
Når jeg kører dette her så får jeg System.Threading.ThreadAbortException.
Jeg får den også hvis jeg gør alt efter kunstens regler og overrider Render metoden for siden. Er det noget man skal leve med, lige som vejret og skatter, eller kan man lukke for den exception og i så fald hvordan ?
Public Sub ExportGridToExcel(ByVal grdGridView As GridView, ByVal fileName As String) 'grdGridView.Visible = False Response.Clear() Response.AddHeader("content-disposition", String.Format("attachment;filename={0}.csv", fileName)) Response.Charset = "" 'Response.ContentType = "application/vnd.xls" Response.ContentType = "text/plain" Response.Write("1,2,3,4" + vbCrLf) Response.Flush() Response.Write("5,6,7,8" + vbCrLf) Response.Flush() ' Dim stringWrite As StringWriter = New StringWriter() ' Dim htmlWrite As HtmlTextWriter = New HtmlTextWriter(stringWrite) ' grdGridView.RenderControl(htmlWrite) ' Response.Write(stringWrite.ToString()) Response.End() ' grdGridView.Visible = True
Yeah . den der med response.redirect har jeg også spildt en masse tid på - og nogle gange kan man kvæle den ved at sætte den anden parameter til false, men ikke altid.
Men betyder det så at vi har vejret, skatten, døden og System.Threading.ThreadAbortException for ever after ? Og uden at kunne flytte til et exception-frit parallelt univers så kan jeg ikke slippe af med den ?:)
Tak for linket og points - jeg kigger sjældent i den afdeling.
lige netop den fejl med Response.Redirect kan man ikke tage helt seriøst. Jeg havde sådan et problem lokalt, men når det blev lagt på serveren så fungerede det fint. Derfor kan jeg kun antage det er en IIS setting der som gør den fejl ikke opstod.
Derfor kan det nok ikke udelukkes 100% om det problem du sidder med kan løses - spørgsmålet er selvfølgelig "hvordan" hvis det kan:)
Næh det har jeg også lært om response.rediret. Det underlige er, at hvis man hjemmestrikker noget login <-> default page halløj med response.redirect, så giver det den exception, mens hvis man i stedet for bruger FormsAuthentication.RedirectFromLoginPage og diverse afarter af denne, så får man INGEN exception !!
Vil lige se om dr_chaos eller en anden har en eller anden kur, if not så må dr_chaos gerne lægge et svar om en stund.
Jeg har brugt begge dele angående login og må indrømme, at der fik jeg ikke fejlen:)
I min situation lavede jeg Response.Redirect fra min maskine til en server og det gav den fejl, men da jeg flyttede koden til serveren (som nu Response.Redirecter til en side hos sig selv) så forsvandt fejlen.
Det finder jeg ulogisk, men om ikke andet så er det fint - project done:O)
Med Response.Redirect kan du bruge Response.Redirect("enurl",false); Grunden til at man får ThreadAbort er at den tråd som applikationenen kører på slutter. Både med response.redirect og response.end. FormsAuthentication.RedirectFromLoginPage bruger formodentlig Response.Redirect("enurl",false);
Du kan bare smide en try catch om din reponse end og dermed håndterer exception. Den skal bare ignoreres.
Ellers prøv denne her som de skriver i det link jeg har skrevet: For Response.End, call the HttpContext.Current.ApplicationInstance.CompleteRequest method instead of Response.End to bypass the code execution to the Application_EndRequest event.
Tak. har prøvet med try/catch, men det tog den ikek så tungt. Uanset, så synes det at være et perfektionistisk problem, så det fejer jeg ind under skærmen.
Prøver lige ved lejlighed dit tip om kalde httpcontext und zo weiter.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
