Occurs during the process of ending the connection between previously connected WebPart or server controls.
Assembly: System.Web (in System.Web.dll)
The 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 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 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 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 event cannot be cancelled in this scenario.
The third scenario in which the 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 event, by design there is no possibility of canceling the event.