Server.Transfer or Server.Execute vs WebClient

  • Thread starter Thread starter ewolfman
  • Start date Start date
E

ewolfman

Hi,

This may sound a little complicated, but here goes:

I have 2 webforms (lets call them 'x' and 'y').

* - 'x' is a form which contains a single server side TextBox web
control, and an iframe.
The iframe's src attribute references the 'y' webform.

* - The 'y' webform has a server side button, and a textbox of the
exact same name as 'x's textbox.

Now here comes the hard part (to explain / understand):
When clicking the 'y's button, 3 things happen:
1. On the client-side, I copy 'x's textbox value to 'y's textbox.
2. 'y' posts back to the server.
3. 'y's button_click event handler creates a WebClient and performs
UploadValues with the TextBox's value (using post method).

This works great, and believe it or not, the new 'x' instance now has a
TextBox control with the correct value at its Text property.

However, if I change the WebClient to a Server.Transfer (or
Server.Execute for that matter - same thing), 'x's textbox contains
nothing on the server side.

When I activated the Trace, I saw that the WebClient's trace went
through the entire ProcessRequest of the Page, where as the
Server.Transfer's trace stopped right after "Begin Load" (probably at
the LoadRecursive function.

I was wondering if anyone has an idea, why the difference between the
two.

Thanks.
 
Server.Transfer is designed to cease execution and directly transfer to the
specified URL
 
Hi Terry,

As I've written, Server.Transfer or Server.Execute - it doesn't matter.
Server.Transfer calls Server.Execute, but simply doesn't return the
control's execution.

So this isn't the answer.

However, I did manage to find the problem. The loading process of the
Page determines on how to load the page, using the IsPostback property.
The IsPostback property for a Server.Transfer returns false (in
contrast to the WebClient.UploadValues), because the context's handler
isn't the same as the target page, and the ServerExecuteDepth is
greater than 0 (in contrast to the WebClient effect).

Therefore - the following 2 lines (before calling the Server.Transfer)
- seem to have solved the problem:

type = Type.GetType("ASP.default_aspx");
HttpContext.Current.Handler =
(IHttpHandler)Activator.CreateInstance(type);

Thanks anyway.
 
Did you try this with the additional attribute which preserves the context
and form variables on transfer ?
 
Back
Top