artificially persisted web controls cause problems with the aspx handler

Discussion in 'ASP .Net' started by PJ6, Jul 24, 2007.

  1. PJ6

    PJ6 Guest

    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
    PJ6, Jul 24, 2007
    #1
    1. Advertising

  2. PJ6

    PJ6 Guest

    Re: artificially persisted web controls cause problems with the aspx handler (solved)

    I changed Response.End to
    HttpContext.Current.ApplicationInstance.CompleteRequest and now everything
    is fixed. I had incorrectly assumed the problem was coming from the novel
    direction of the web project.

    Paul

    "PJ6" <> wrote in message
    news:...
    > 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
    >
    PJ6, Jul 24, 2007
    #2
    1. Advertising

  3. PJ6

    bruce barker Guest

    Re: artificially persisted web controls cause problems with the aspxhandler

    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
    >
    >
    bruce barker, Jul 24, 2007
    #3
  4. PJ6

    PJ6 Guest

    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" <> wrote in message
    news:...
    > 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, Jul 25, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Toby Mills
    Replies:
    0
    Views:
    1,563
    Toby Mills
    Jun 24, 2003
  2. Tom Jorgenson
    Replies:
    0
    Views:
    517
    Tom Jorgenson
    Jul 17, 2003
  3. Anthony P. Mancini
    Replies:
    8
    Views:
    410
    Victor Garcia Aprea [MVP]
    May 8, 2004
  4. VB Programmer

    Dataset not persisted on PostBack

    VB Programmer, Jun 5, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    388
    =?Utf-8?B?SmltIEhldmV5?=
    Jun 6, 2004
  5. Eran Amitai
    Replies:
    4
    Views:
    192
    Eran Amitai
    Jan 7, 2004
Loading...

Share This Page