Gets a reference to the server control's naming container, which creates a unique namespace for differentiating between server controls with the same Control.ID property value.(Inherited from Control.)

This API supports the product infrastructure and is not intended to be used directly from your code.
Gathers information about the server control and delivers it to the Trace property to be displayed when tracing is enabled for the page.(Inherited from Control.)

This API supports the product infrastructure and is not intended to be used directly from your code.
Sets the ClientIDMode property of the current control instance and of any child controls to Inherit.(Inherited from Control.)

Called by the ASP.NET page framework to notify server controls that use composition-based implementation to create any child controls they contain in preparation for posting back or rendering.(Inherited from Control.)

This API supports the product infrastructure and is not intended to be used directly from your code.
Searches the current naming container for a server control with the specified id and an integer, specified in the pathOffset parameter, which aids in the search. You should not override this version of the FindControl method.(Inherited from Control.)

This API supports the product infrastructure and is not intended to be used directly from your code.
Assigns an event handler delegate to render the server control and its content into its parent control.(Inherited from Control.)

Causes tracking of view-state changes to the server control so they can be stored in the server control's StateBag object. This object is accessible through the Control.ViewState property.(Inherited from Control.)

The ProxyWebPartManager control exists for the particular scenario of declaring static connections in content pages when a WebPartManager control has already been declared in a master page.

By design, 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 place the WebPartManager control in the master page, because all the content pages are merged with the master page at run time and the single WebPartManager control will manage all the Web Parts controls from all content pages. However, when developers want to declare static connections in the content pages of such an application, they might seem to face a limitation. A static Web Parts connection can be declared only by adding an <asp:webpartconnection> element as a child of a <staticconnections> element, which itself must be a child of a <asp:webpartmanager> element. But because the WebPartManager control was already declared in the master page, and is the one permitted WebPartManager control, developers cannot declare additional WebPartManager controls in the content pages to add static connections.

The ProxyWebPartManager control takes the place of the WebPartManager control in this scenario. Developers declare an <asp:proxywebpartmanager> element instead of an <asp:webpartmanager> element in their content pages, and can then declare static connections as child elements. At run time, the connections in the ProxyWebPartManager control are simply added to the StaticConnections collection of the WebPartManager control and treated like any other connection.

Because the ProxyWebPartManager control is used only in this particular development scenario, it has more limited functionality than the WebPartManager class. In fact, 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. It inherits directly from the Control class, and overrides only a few of the base members. The EnableTheming, Visible, and SkinID properties are overridden and assigned values that prevent them from being used. Other inherited properties are overridden to adjust their design-time behavior, but otherwise they have the same behavior as the base properties. These include the Controls and ClientID properties. Finally, the ProxyWebPartManager class has one non-inherited property. The StaticConnections property returns its own collection of static connections (a ProxyWebPartConnectionCollection object).

As for methods, the ProxyWebPartManager class similarly overrides only a few methods, mostly to restrict their use. The inherited Focus method is made unusable by throwing an exception if called. The CreateControlCollection method always returns an empty control collection, which has the effect of preventing it from being able to contain a collection of controls. Finally, the OnInit method calls the base method, and then assigns the collection of connections referenced by the StaticConnections property to the WebPartManager.StaticConnections property of the WebPartManager control. This has the effect of rolling up all the static connections declared in all content pages and making them part of the connections collection maintained by the WebPartManager control in the master page.

The following code example demonstrates how to use the ProxyWebPartManager class to declare static connections on content pages in an application that uses master pages. The example has five parts:

A user control that enables you to change the Web Parts display mode on a page.

Source code for an interface and two WebPart controls acting as the provider and the consumer for a connection.

A master Web page that hosts the user control, the content pages, and the WebPartManager control for the application.

A content Web page that hosts a ProxyWebPartManager control, the two custom WebPart controls, and a static connection to connect the two controls.

An explanation of how to run the example page.

The first part of this code example is the user control that enables users to change display modes on a Web page. Save the following source code to an .ascx file, giving it the file name that is assigned to the Src attribute of the Register directive for this user control, which is near the top of the hosting master page. For details about display modes and a description of the source code in this control, see Walkthrough: Changing Display Modes on a Web Parts Page.

The second part of the code example is the source code for the interface and controls. The source file contains a simple interface named IZipCode. There is also a WebPart class named ZipCodeWebPart that implements the interface and acts as the provider control. Its ProvideIZipCode method is the callback method that implements the interface's only member. The method simply returns an instance of the interface. Note that the method is marked with a ConnectionProvider attribute in its metadata. This is the mechanism for identifying the method as the callback method for the provider's connection point. The other WebPart class is named WeatherWebPart, and it acts as the consumer for the connection. This class has a method named GetZipCode that gets an instance of the IZipCode interface from the provider control. Note that this method is marked as the consumer's connection point method with a ConnectionConsumer attribute in its metadata.

For the code example to run, you must compile this source code. You can compile it explicitly and put the resulting assembly in your Web site's Bin folder or the global assembly cache. Alternatively, you can put the source code in your site's App_Code folder, where it will be dynamically compiled at run time. This code example uses dynamic compilation. For a walkthrough that demonstrates how to compile, see Walkthrough: Developing and Using a Custom Web Server Control.

The third part of the code example is the master page. You should take the following source code and save it in a file, naming it MasterPageCS.master or MasterPageVB.master (depending on which language you use). Note that the master page contains a Register directive to register the user control, and it references the user control itself in the body of the page. The master page also declares the single <asp:webpartmanager> element used for this page and all related content pages. Finally, the master page has an <asp: contentplaceholder> element that declares the point in the page where the content page is inserted.

The fourth part of the code example is the content page. You should copy the following source code and save it in a file with an .aspx extension. Notice that its Page directive contains a MasterFile attribute to refer to the master page. Also, this page has a Register directive to register the file in the App_Code folder that contains the dynamically compiled custom WebPart controls that participate in the connection. Within the <asp:content> tags of the page, there is an <asp:proxywebpartmanager> element, with a child <staticconnections> element, which in turn has a child <asp:webpartconnection> element to declare the details of the connection. Within the <script> tags on the page, the Button1_Click method adds some code that accesses the main WebPartManager control in the master page and the ProxyWebPartManager control in the content page, and writes some of their details to the page.

After you load the page in a browser, click the WebPartManager Information button and observe the information about the WebPartManager control in the master page, and the ProxyWebPartManager control in the content page. For example, note that they both have the same count in their respective properties that track static connections (the StaticConnections property). Note also that although the WebPartManager control has a WebParts property that tracks the number of WebPart controls it manages, the ProxyWebPartManager control has no such property, as its only purpose is to contain static connections.