tags:

views:

629

answers:

3

I'm having some problems with Server.Execute that I can't seem to find any details on.

Page page = new WidgetProcessor(Widget);
Server.Execute(page, htmlTextWriter, true);

The Widget in the above code is a simple object that knows how to instantiate a usercontrol. The WidgetProcessor takes a Widget and adds the widgets control to the page. This works fine on the initial load, it doesn't seem to handle postbacks however; it never actually fires the user controls events, it just consistently returns the original page as if you had never posted back.

I've found this article from 2003: http://support.microsoft.com/kb/817036, though I would think they would have fixed this by now.

Any help would be appreciated.

A: 

I'm guessing that since you are adding controls dynamically to the page, they are not being registered into viewstate at the right time and are therefore getting lost. When using dynamic controls you have to re-add the controls with the same id so they are picked up and can therefore register postbacks.

Adam Fyles
This isn't the issue, the page events work perfectly fine so long as I'm accessing it directly and not using Server.Execute.
justin
A: 

You need to load the control before the Page_Load is run. OnInit is usually where it's done. This means that the control will be registered BEFORE ViewState track changes is turned on by ASP.NET. Change tracking is turned on (just before Page_Load is fired) all changes to ViewState for that control will be treated as dirty and thus there will be no difference between the initial values and the changed values. Also The ViewState engine won't be able to tell if the values have changed on a postback if the control is loaded after change tracking is turned on as it doesn't have the original values to compare against.

Jonathan Parker
This isn't the issue, the page events work perfectly fine so long as I'm accessing it directly and not using Server.Execute.
justin
A: 

When Server.Execute is used, a URL is passed to it as a parameter, and the control moves to this new page. Execution of code happens on the new page. Once code execution gets over, the control returns to the initial page, just after where it was called. However, in the case of Server.Transfer, it works very much the same, the difference being the execution stops at the new page itself (means the control isn’t returned to the calling page). In both the cases, the URL in the browser remains the first page URL (doesn’t refresh to the new page URL) as the browser isn’t requested to do so.

Vijay Pareek