Gets a value that indicates whether custom personalization state data managed by the WebPartManager control has changed on a Web page.
Assembly: System.Web (in System.Web.dll)
The WebPartManager control has changed. When users personalize page-level details, for example by changing page layout, creating or deleting connections, and adding or deleting controls, the personalization data managed by the WebPartManager control changes. This is a pass-through method that returns to callers the value of the protected IsCustomPersonalizationStateDirty property, which cannot be directly accessed by callers.property provides a way for callers to determine whether personalization state data that is managed by the
The WebPart controls, have changed. Control-level personalization is tracked for each control individually. The property indicates only whether personalization data that is at the page level and is managed by the WebPartManager control has changed.property does not indicate whether personalizable property values, or individual properties that affect the appearance of individual
The following list describes some common instances of personalization that would cause the WebPartManager control has some changed personalization data:property to return a value of true, indicating that the
Closing a static WebPart control (or server or user control) on a page.
Restoring a closed static WebPart control from a page catalog back to a page.
Moving any control within its zone or to another zone.
Adding a control from a catalog of WebPart or server controls, or adding a control programmatically.
Creating a connection between two WebPart controls, either programmatically or by using the connection user interface (UI).
Deleting a connection between two WebPart controls, either programmatically or by using the connection UI.
The following code example demonstrates a simple usage of the WebPartManager control's personalization data to change.property, to indicate some common page personalization instances that cause a
The code example has four parts:
A user control that allows you to change display modes on a page that contains Web Parts controls.
A source file that contains the code for two custom WebPart controls that can be connected, and an interface.
A Web page that hosts all the controls.
An explanation of how the code example works.
The first part of the code example is the user control for changing display modes. You can obtain the source code for the user control from the Example section of the WebPartManager class overview. For information about display modes and how the user control works, see Walkthrough: Changing Display Modes on a Web Parts Page.
The second part of the example is the source file with the custom controls and the interface. Notice that the IZipCode interface exposes one method, and that this method as implemented in the custom ZipCodeWebPart control serves as a callback method to enable ZipCodeWebPart to act as a provider in a connection scenario. The other control, WeatherWebPart, acts as the consumer control in a connection; it can consume the particular interface provided by ZipCodeWebPart. In a real application, WeatherWebPart could consume a personalized ZIP Code value from the provider, and then provide graphical weather information to users.
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; therefore, notice that the Register directive for this component at the top of the Web page contains only TagPrefix and Namespace attributes, without an Assembly attribute. 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 Web page. Notice that it contains two WebPartZone zones, with the first one containing the two custom WebPart controls. There is also a CatalogZone zone, which contains a standard Calendar control that users can add to the page. The <asp:connectionszone> element provides a connection UI for users to create connections between controls. In the Page_PreRender method, notice that it checks to see whether the personalization data has changed and, if so, updates the text of Label1.
After you load the page in a browser, try to create some of the scenarios listed in the Remarks section of this topic that will change the personalization data. As you make various changes, when a change involves one of the personalization scenarios tracked by the WebPartManager control, the text of the Label1 control is displayed to indicate that personalization data has changed. For example, you can:
Create a connection between controls by clicking the Connect WebPart Controls button.
Use the Display Mode drop-down list control to switch the page to catalog mode, and add the My Calendar control to the second WebPartZone zone.
Change the page back to browse mode, click on the verbs menu (shown with an arrow symbol in the title bar) for the My Calendar control, and select Close to close it and add it to the page catalog.
Return the page to catalog mode, and add the My Calendar control back to the page.
Use the Display Mode control to switch the page to design mode, and rearrange the layout of the controls by dragging one or more of them to another zone, or to a different position in the same zone.
Available since 2.0