469,268 Members | 1,025 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,268 developers. It's quick & easy.

Server.Transfer or Server.Execute vs WebClient

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.

Feb 12 '06 #1
4 2135
Server.Transfer is designed to cease execution and directly transfer to the
specified URL

--
Terry Burns
http://TrainingOn.net

"ewolfman" <ew******@yahoo.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com...
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.

Feb 12 '06 #2
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.

Feb 12 '06 #3
Did you try this with the additional attribute which preserves the context
and form variables on transfer ?

--
Terry Burns
http://TrainingOn.net
"ewolfman" <ew******@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
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.

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

Feb 13 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Srini | last post: by
5 posts views Thread by Paul de Goede | last post: by
9 posts views Thread by Mark | last post: by
5 posts views Thread by Guadala Harry | last post: by
18 posts views Thread by UJ | last post: by
5 posts views Thread by Richard | last post: by
3 posts views Thread by David Veeneman | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.