LibreOffice 24.2 SDK API Reference
Public Member Functions | List of all members
XCloseable Interface Referencepublished

makes it possible to release any objects in an ordered manner by using a two-step mechanism More...


Inheritance diagram for XCloseable:
XCloseBroadcaster XInterface XEmbeddedObject XReportDefinition OfficeDatabaseDocument AsyncJob Job ReportDefinition

Public Member Functions

void close ([in] boolean DeliverOwnership) raises ( CloseVetoException )
 try to close the object More...
- Public Member Functions inherited from XCloseBroadcaster
void addCloseListener ([in] XCloseListener Listener)
 adds the specified listener to receive or have a veto for "close" events More...
void removeCloseListener ([in] XCloseListener Listener)
 removes the specified listener More...
- Public Member Functions inherited from XInterface
any queryInterface ([in] type aType)
 queries for a new interface to an existing UNO object. More...
void acquire ()
 increases the reference counter by one. More...
void release ()
 decreases the reference counter by one. More...

Detailed Description

makes it possible to release any objects in an ordered manner by using a two-step mechanism

If an object should be terminated, it can be:

First version gives the object no chance to disagree with that (e.g. if a process is still running and can't be canceled really). Last version provides this possibility, but can't guarantee real termination of called object. It depends from the environment of an object, if one or both mechanism are necessary.

Base interface XCloseBroadcaster makes it possible that any listener which is interested on life time of listened object ...

See also
Developers Guide
Office Development - Closing Documents

Member Function Documentation

◆ close()

void close ( [in] boolean  DeliverOwnership)
raises (CloseVetoException

try to close the object

Must definitely be called before com::sun::star::lang::XComponent::dispose(). But nobody can guarantee real closing of called object - because it can disagree with that if any still running processes can't be canceled yet. It's not allowed to block this call till internal operations will be finished here. They must be canceled or call must return immediately by throwing the CloseVetoException. Otherwise (if nothing exist to disagree) it must return normally.

Before any internal processes will be canceled, all registered XCloseListener must be notified. Any of them can disagree with a CloseVetoException too. It's forbidden to catch this exception inside the called close() method because the caller must get this information!

If somewhere disagree with a CloseVetoException it will not clear who has to close the object again after still running processes was finished. The parameter DeliverOwnership regulate that. If it is set to FALSE the caller of the method close() will be the owner of this object in every case. Then it's not allowed to call close() from any other place (may a registered XCloseListener). If it is set to TRUE the caller gives up his ownership. If a XCloseListener throw the veto exception he will be the new owner of the closing object. This information is passed to the listener by a parameter of his notification method XCloseListener::queryClosing(). After his operations was finished he MUST try to close it again. If the closing object itself disagree by an exception and the parameter DeliverOwnership was set to TRUE the object will be his own owner with all consequences of that.
There is no way to get the ownership back if it was delivered!

If this method was already called on an object it should return without any reaction. Normally it's possible to throw a com::sun::star::lang::DisposedException for already disposed or closed objects (which represent a com::sun::star::uno::RuntimeException and can be thrown by every interface call), but it shouldn't be used here. The veto exception should be the only way to indicates the result.

DeliverOwnershipTRUE delegates the ownership of this closing object to anyone which throw the CloseVetoException. This new owner has to close the closing object again if his still running processes will be finished.
FALSE let the ownership at the original one which called the close() method. He must react for possible CloseVetoExceptions and try it again at a later time. This can be useful for a generic UI handling.
CloseVetoExceptionindicates that the closing object himself or any of his currently registered listener disagree with this close() request.
See also

The documentation for this interface was generated from the following file: