Server.Transfer or Server.Execute vs WebClient

[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.

 

[Terry Burns]

Server.Transfer is designed to cease execution and directly transfer to the
specified URL

 

[ewolfman]

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.

 

[Terry Burns]

Did you try this with the additional attribute which preserves the context
and form variables on transfer ?

 

[ewolfman]

if you refer to the 'preserveForm', then the answer is yes (i.e. it is
set to true).