/************************************************************************* * * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * Copyright 2008 by Sun Microsystems, Inc. * * OpenOffice.org - a multi-platform office productivity suite * * $RCSfile: FormControllerDispatcher.idl,v $ * $Revision: 1.6 $ * * This file is part of OpenOffice.org. * * OpenOffice.org is free software: you can redistribute it and/or modify * it under the terms of the GNU Lesser General Public License version 3 * only, as published by the Free Software Foundation. * * OpenOffice.org is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU Lesser General Public License version 3 for more details * (a copy is included in the LICENSE file that accompanied this code). * * You should have received a copy of the GNU Lesser General Public License * version 3 along with OpenOffice.org. If not, see * * for a copy of the LGPLv3 License. * ************************************************************************/ #ifndef __com_sun_star_form_FormControllerDispatcher_idl__ #define __com_sun_star_form_FormControllerDispatcher_idl__ #ifndef __com_sun_star_frame_XDispatchProvider_idl__ #include #endif //============================================================================= module com { module sun { module star { module form { //============================================================================= /** specifies a component which can be used to dispatch form controller functionality.

A form controller dispatcher is an instance which provides access to dispatchers (XDispatch) for certain form controller functionality.

The way how access to these dispatchers is provided is not defined. It may either be directly via an XDispatchProvider interface, or indirectly, e.g. by registering dispatch interceptors (XDispatchProviderInterceptor) at another instance which supports this (by exposing the XDispatchProviderInterception interface).

In any scenario, foreign components have a (implicit or explicit) possibility to request a dispatcher for a given URL.

Below, there's a list of URLs which have a defined meaning - if a FormControllerDispatcher implementation supports one of them, there must be a guaranteed semantices. However, concrete implementations may support an arbitrary sub or super set of these URLs.

In general, all URLs start with the same prefix, namely .uno:FormController/. To this, a suffix is appended which describes the requested functionality.
Example: The URL suffix for deleting the current record is deleteRecord, so the complete URL for requesting a dispatcher for this functionality is .uno:FormController/deleteRecord.

Some URLs may require parameters. For this, the sequence of PropertyValues passed to the XDispatch::dispatch call is used - every property value is used as one named parameter.

For all URLs, interested parties can register as status listeners (XStatusListener) at the dispatchers, and be notified whenever the functionality associated with the URL becomes enabled or disabled.
For instance, the URL with the suffix moveToFirst is associated with moving the form to the first record, and it will be disabled in case the form is already positioned on the first record.

Nearly all of the functionality offered by a FormControllerDispatcher can also be reached by other means. E.g., moving a form to its first record can be achieved by calling the method XResultSet::first of the form.
However, the advantage of using a FormControllerDispatcher is that it's usually implemented by a component which has additional knowledge about the form. For instance, in a document which displays a form, there might be a control which contains uncommitted changes, plus a control whose changes were already committed to the current record, but not to the database. Simply calling XResultSet::first on the form would lose both the content in the uncommitted control, and the changes in the current record.
An FormControllerDispatcher is expected to care for both of these.

URL suffix functionality
positionForm positions the form on a record given by absolute number.
There's one parameter for this functionality, named Position, which must be a long value specifying the absolute position to which the form should be moved
RecordCount This is a passive functionality: It cannot be dispatched, instead, interested parties may use the dispatcher to add as XStatusListener, and be notified when the record count changes.
The status value which is being notified (FeatureStateEvent::State) is a string which can be used to display the record count. In particular, if the record count is not yet known (RowSet::IsRowCountFinal is ), this is indicated in the string, too.
moveToFirst moves the form to the first record
moveToPrev moves the form to the record preceding the current one
moveToNext moves the form to the record after the current one
moveToLast moves the form to the last record
moveToNew moves the form to the virtual "insert row", where new records can be inserted
saveRecord Commits any potentially pending changes in the current control, and saves the current record to the database, or inserts a new record if the form is currently positioned on the virtual insertion row.
undoRecord reverts the changes done to the current record. Basically, this means refreshing the current row from the database, and updating all controls with the new content.
deleteRecord deletes the current record, after asking the user for confirmation.
refreshForm reloads the complete form. After this, the form is positioned on the first record
sortUp Adds an order clause to the form, to sort it ascending by the field which the current control is bound to, and then reloads the form.
sortDown Adds an order clause to the form, to sort it descending by the field which the current control is bound to, and then reloads the form.
sort opens an dialog, which allows the user to manipulate the current sorting order of the form. If the dialog is closed with OK, the form is reloaded after setting the new sorting order.
autoFilter creates, from the current control, a filter for the form. This is, if the current control is bound to the field, say, "customer", and contains the value "Furs, Inc.", then a filter "customer = 'Furs, Inc.'" is created and set at the form. After this, the form is reloaded.
filter opens an dialog, which allows the user to manipulate the current filter of the form. If the dialog is closed with OK, the form is reloaded after setting the new filter.
applyFilter

Toggles the RowSet::ApplyFilter property of the form.

Additionally, status listeners will be provided with the current (boolean) state of this property in the FeatureStateEvent::State member of the event notified by the dispatcher.

removeFilterOrder completely removes any filter and sorting order from the form, and reloads it.
@see FormController */ published service FormControllerDispatcher { //------------------------------------------------------------------------- /** allows direct access to the dispatchers provided by the component. */ [optional] interface com::sun::star::frame::XDispatchProvider; }; //============================================================================= }; }; }; }; /*============================================================================= =============================================================================*/ #endif