ProxyWebPartManager Web Server Control Overview
This topic contains:
A Web page that uses Web Parts controls must contain one (and only one) WebPartManager control that manages all Web Parts controls on the page. When a Web Parts application uses master pages, it is common to put the WebPartManager control in the master page. When content pages are merged with the master page at run time, the single WebPartManager control can manage Web Parts controls on all the content pages.
Declaring a static connection ordinarily requires that you add an asp:webpartconnection element as a child of a staticconnections element, which must be a child of an asp:webpartmanager element. However, when you use master pages and put the WebPartManager control in the master page, you cannot create a asp:webpartmanager element in a content page. This is because only one WebPartManager control is permitted. The solution is to use a ProxyWebPartManager control on the content page, which takes the place of the WebPartManager control.
For a code example that shows how to use the ProxyWebPartManager class, see the "Example" section of System.Web.UI.WebControls.WebParts.ProxyWebPartManager.
Differences Between the ProxyWebPartManager Control and the WebWebManager Control
The ProxyWebPartManager control is used only when you have created a WebPartManager control in a master page and you want to declare static connections in the content page. The ProxyWebPartManager control therefore has more limited functionality than the WebPartManager control. Although the ProxyWebPartManager control acts as a proxy to contain static connections for the WebPartManager control in content pages, it does not inherit from the WebPartManager control. Instead, it inherits directly from the Control class and overrides only some of the base members.