You can either get a simple static ::com::sun::star::ucb::ContentResultSet or you can
listen to change-notifications and than swap from the old to a new
::com::sun::star::ucb::ContentResultSet .
The following describes the dynamic use:
::com::sun::star::ucb::XDynamicResultSet provides the possibility to get notifications
about changes on a ::com::sun::star::ucb::ContentResultSet and have an
listener-controlled update from one version to the next version. Two
::com::sun::star::ucb::ContentResultSet implementations were given to the listener in
the first notification as interface
::com::sun::star::sdbc::XResultSet .
To get notifications the listener has to be of type
::com::sun::star::ucb::XDynamicResultSetListener .
After registration you will get notifications for events of type
::com::sun::star::ucb::ListEvent .
The calling of ::com::sun::star::ucb::XDynamicResultSetListener::notify has
to happen in an own thread, because it could take a longer time and any
actions til the listener returns the call. So don't block the notify-causing
action.
While one notify-call is going on:
- The listener is allowed to access both ::com::sun::star::ucb::ContentResultSet s,
they must be both valid.
- It is not allowed to start a second notify-call.
- All addditional things we want to send as notification are to be
queued.
- Any other calls are to be accepted and treated.
After the listener has returned the notify-call:
- The listener is allowed to access the new
::com::sun::star::ucb::ContentResultSet . The new one is first assigned in the
WELCOME-event and than the ResultSets are always swapped.
- The listener is not allowed to access the old
::com::sun::star::ucb::ContentResultSet .