Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > artificially persisted web controls cause problems with the aspx handler

Reply
Thread Tools

artificially persisted web controls cause problems with the aspx handler

 
 
PJ6
Guest
Posts: n/a
 
      07-24-2007
Taken out of context I know this may seem like a strange thing to do, but
just take this as an academic question if necessary...

Calling methods on a persisted control that has been added to a page that
has been rendered and unloaded generates these exceptions -

A first chance exception of type 'System.Net.Sockets.SocketException'
occurred in System.dll
A first chance exception of type 'System.Threading.ThreadAbortException'
occurred in mscorlib.dll
A first chance exception of type 'System.Threading.ThreadAbortException'
occurred in System.Web.dll

This happens even if I take the control out of the original page, and
regardless whether I persist it as a static or a session variable.

Now I really wouldn't care about these silent errors, provided they didn't
affect anything, but this is not the case; web projects with persisted
controls tend to hang on startup - the beginning page's render method is
fired, but the browser load continues indefinitely, and pausing execution
just shows dissassembly.

Why don't I just handle .aspx myself... well I don't have access to the
methods that properly load pages. I would have to use my own control
classes, not based on any of the existing object model already provided.
Certainly doable considering I do not need view state, but this would
require additional work that I have to justify. I will be making my own
control base classes later, but the render output will not be HTML.

So... the question is, is there anyone with suffcient knowledge of the
internal workings of the .aspx handler to tell me if it is possible to
persist already rendered controls without a problem?

Paul


 
Reply With Quote
 
 
 
 
PJ6
Guest
Posts: n/a
 
      07-24-2007
I changed Response.End to
HttpContext.Current.ApplicationInstance.CompleteRe quest and now everything
is fixed. I had incorrectly assumed the problem was coming from the novel
direction of the web project.

Paul

"PJ6" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Taken out of context I know this may seem like a strange thing to do, but
> just take this as an academic question if necessary...
>
> Calling methods on a persisted control that has been added to a page that
> has been rendered and unloaded generates these exceptions -
>
> A first chance exception of type 'System.Net.Sockets.SocketException'
> occurred in System.dll
> A first chance exception of type 'System.Threading.ThreadAbortException'
> occurred in mscorlib.dll
> A first chance exception of type 'System.Threading.ThreadAbortException'
> occurred in System.Web.dll
>
> This happens even if I take the control out of the original page, and
> regardless whether I persist it as a static or a session variable.
>
> Now I really wouldn't care about these silent errors, provided they didn't
> affect anything, but this is not the case; web projects with persisted
> controls tend to hang on startup - the beginning page's render method is
> fired, but the browser load continues indefinitely, and pausing execution
> just shows dissassembly.
>
> Why don't I just handle .aspx myself... well I don't have access to the
> methods that properly load pages. I would have to use my own control
> classes, not based on any of the existing object model already provided.
> Certainly doable considering I do not need view state, but this would
> require additional work that I have to justify. I will be making my own
> control base classes later, but the render output will not be HTML.
>
> So... the question is, is there anyone with suffcient knowledge of the
> internal workings of the .aspx handler to tell me if it is possible to
> persist already rendered controls without a problem?
>
> Paul
>



 
Reply With Quote
 
 
 
 
bruce barker
Guest
Posts: n/a
 
      07-24-2007
most of the server controls use viewstate to hold all property values,
so you will need a valid viewstate. the render streams and the Page
object are also invalid.

if you want to persists controls, you should make a persisted page, then
add them to the page.

-- bruce (sqlwork.com)



PJ6 wrote:
> Taken out of context I know this may seem like a strange thing to do, but
> just take this as an academic question if necessary...
>
> Calling methods on a persisted control that has been added to a page that
> has been rendered and unloaded generates these exceptions -
>
> A first chance exception of type 'System.Net.Sockets.SocketException'
> occurred in System.dll
> A first chance exception of type 'System.Threading.ThreadAbortException'
> occurred in mscorlib.dll
> A first chance exception of type 'System.Threading.ThreadAbortException'
> occurred in System.Web.dll
>
> This happens even if I take the control out of the original page, and
> regardless whether I persist it as a static or a session variable.
>
> Now I really wouldn't care about these silent errors, provided they didn't
> affect anything, but this is not the case; web projects with persisted
> controls tend to hang on startup - the beginning page's render method is
> fired, but the browser load continues indefinitely, and pausing execution
> just shows dissassembly.
>
> Why don't I just handle .aspx myself... well I don't have access to the
> methods that properly load pages. I would have to use my own control
> classes, not based on any of the existing object model already provided.
> Certainly doable considering I do not need view state, but this would
> require additional work that I have to justify. I will be making my own
> control base classes later, but the render output will not be HTML.
>
> So... the question is, is there anyone with suffcient knowledge of the
> internal workings of the .aspx handler to tell me if it is possible to
> persist already rendered controls without a problem?
>
> Paul
>
>

 
Reply With Quote
 
PJ6
Guest
Posts: n/a
 
      07-25-2007
How would you recommend creating a persisted page (differently than how the
default aspx hadler does it?) and ensuring that it is properly initialized
(OnInit/OnLoad recusrive)?

Paul

"bruce barker" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> most of the server controls use viewstate to hold all property values, so
> you will need a valid viewstate. the render streams and the Page object
> are also invalid.
>
> if you want to persists controls, you should make a persisted page, then
> add them to the page.
>
> -- bruce (sqlwork.com)



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Artificially limit total RAM in XP Dogboy NZ Computing 4 03-16-2011 01:07 AM
Question: Artificially aging digital photos BD Digital Photography 8 07-15-2005 08:12 PM
Is it possible to artificially trigger dropdownlist event on server? Eran Amitai ASP .Net Web Controls 4 01-07-2004 04:29 PM
How do you save persisted (between runs) login information in .NET (c#)? Tom Jorgenson ASP .Net 0 07-17-2003 04:46 PM
style.display setting not persisted in viewstate Toby Mills ASP .Net 0 06-24-2003 01:55 PM



Advertisments