Assembly: System.Web (in system.web.dll)
/** @event */ public void add_WebPartsDisconnecting (WebPartConnectionsCancelEventHandler value) /** @event */ public void remove_WebPartsDisconnecting (WebPartConnectionsCancelEventHandler value)
In JScript, you can handle the events defined by a class, but you cannot define your own.
The WebPartsDisconnecting event is raised by the OnWebPartsDisconnecting method, and it signals the fact that a user has clicked a disconnect verb, or the DisconnectWebParts method has otherwise been called. The event provides an opportunity to cancel the process of ending a connection before it is complete. If the connection is ended successfully, this event is followed by the WebPartsDisconnected event.
Page developers can add a custom handler for the event by adding the OnWebPartsDisconnecting attribute to the <asp:webpartmanager> element, and assigning a custom method name to the attribute.
Normally, when the WebPartsDisconnecting event is raised as a direct result of a user's action that ends a connection, the event can be cancelled. However, there are several scenarios in which the event cannot be cancelled. The first scenario is, if a WebPartZone control is deleted, the WebPart controls it contains must all be closed, otherwise they would be orphaned. In this case the WebPartManager control closes the WebPart controls, not the user, and it must also be able to terminate the connections of any connected controls without any chance of interruption, so that it can complete the process of cleaning up and closing all the controls. Therefore, by design the WebPartsDisconnecting method cannot be cancelled in this scenario. For a related event that can be cancelled, see the WebPartClosing event.
The second scenario in which the WebPartsDisconnecting event cannot be cancelled is when the ActivateConnections method is called (this called during each request to a page, for example), and there is some type of conflict in the existing connections on a page. For example, perhaps a user connects control x to control y, but a shared user connects control x to control z, and yet control x is not allowed to form multiple connections. In this case, the individual user's settings for the connection take precedence, and the WebPartManager control resolves the conflict by calling the DisconnectWebPart method and ending the connection between x and z for the particular user. Because this disconnection is essential to resolving the conflict, by design the WebPartsDisconnecting event cannot be cancelled in this scenario.
The third scenario in which the WebPartsDisconnecting method cannot be cancelled is when a WebPart or server control that is currently connected is either deleted or closed. Because the control is definitely going to be removed from the page, it is a logical necessity to remove its connection. Therefore, when the WebPartManager control invokes the DisconnectWebPart method, which in turn raises the WebPartsDisconnecting event, by design there is no possibility of canceling the event.
Windows 98, Windows Server 2000 SP4, Windows Millennium Edition, Windows Server 2003, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP SP2, Windows XP Starter EditionThe Microsoft .NET Framework 3.0 is supported on Windows Vista, Microsoft Windows XP SP2, and Windows Server 2003 SP1.