Hi Fernand,

> Do this means that we now can "load" a Form starting from  the 
> connection and not obligatory from a open DBDocument  ?

Nothing changed there, sorry: A connection still is subordinate to the
database document - there can be connections without an associated
database document, but a database document has (or can obtain) a
connection. Forms then are also subordinate to a database document. So,
the entry point for all form/report/etc. work is still the DB doc.

What the mail tried :-\ to express is that formerly, you could only load
existing forms (XDatabaseDocumentUI.loadComponent( DatabaseObject.FORM,
...)), where now you can also easily create new ones via the
createComponent method.


So, after having said that ....

If you have a connection, and *know* that it comes from a DataSource,
then getParent of this connection will give you the data source. A data
source, then, can be asked for its associated database document
(XDocumentDataSource.getDatabaseDocument). The document then has the
forms/reports collection, providing access to the
css.sdb.DocumentDefinition objects. A DocumentDefinition, finally, has
an "open" method.

This is true before and after the change which you replied to.

If you know what you're doing, using this path is perfectly legitimate.
However, the way via the XDatabaseDocumentUI (implemented by the
controller of the database document) is usually to be preferred: If the
user closes the database document, then all sub documents opened/created
via XDatabaseDocumentUI will be closed, too. In this sense, the
interface really only provides convenience shortcuts for actions the
user can do in the UI.

Tampering with the document definitions (and other low level objects)
directly is possible, but gives you who you're doing this the
responsibility for life time etc.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer         frank.schoenh...@sun.com -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org

Reply via email to