Hi Ariel,
> I think that the user is used to what existed up to now: ThisComponent
> refers to the form-document/report document. So changing this one to
> refer to the DatabaseDocument may not be the best user experience ever,
> for those users used to it.
I see the point (which seems to be consensus in the responses).
> May be the new feature can be embodied on a new object variable:
> "DatabaseDocument" (or what ever name), leaving ThisComponent to what
> really is ThisForm or ThisReport. :-(
In every case, there will be a new object variable. So either
ThisComponent or the new one will refer to the form/report, the other to
the database document. The question is: which is which.
Additional thoughs I had over the weekend (I still have no clear opinion
whether they favor one of the two approaches)
1.
One group *will* need to learn something new:
If ThisComponent is the form/report, then people doing
ThisComponent.DialogLibraries.loadLibraries(...) (or similar things
where ThisComponent refers to the document where the Basic is embedded)
need to.
If ThisComponent is the database document, people currently doing
ThisCokmponent.Something need to learn to do GreatNewVariable.Something.
Question is: What hurts less? And: What is more logical? (The answers
might have different weights :)
2.
Be aware that in case of invoking a basic macro from within, say, a
query design, ThisComponent cannot be a document model. In the current
world, it always is. In the new world, only the database document is a
document/model, the GreatNewVariable (which only can point to the
controller of the query design) isn't.
3.
In other script languages, the equivalent of ThisComponent is
XScriptContext.getDocument(). Note the notion saying "that's always a
document".
> IIRC in one of the version of your paper you said that when a macro is
> assigned to an event of a control, the macro gets an event object, and
> it's easy using the Child-Parent hierarchy to get the form document for
> there.
> Here I have my concerns: ...
That was intended to be seen as fallback only.
Bug I take your point that it's way too difficult in many cases.
> The other point: there must be a new way to access a form/report
> document from the DatabaseDocument.
> Up to now
>
> oDatabaseDocument.getFormDocuments().getByName("FormName")
> oDatabaseDocument.getReportDocuments().getByName("ReportName")
>
> just gives me access to the document definition, NOT the document model.
Right.
There is no direct access to the opened sub components. What you can do
is iterating over the children of the frame of the current controller of
the database document. This will give you all open sub components. Not
really elegant, again.
However, obtaining open sub components in a more convenient way is a
different topic. (Though <hint>I'd accept an RFE, if you'd submit
one.</hin>)
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
