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
>
>
|
Similar Threads
