Frank Schönheit - Sun Microsystems Germany escribió:
Hi,
we recently discussed the behavior of "ThisComponent" when macros in
database documents would be implemented, and such macros would be called
from a form or report.
After digging deeper into the topic, I somewhat changed my mind and in
fact think we need to introduce another global variable, to differ
between "the document where the macro is located" and "the document from
where the macro was called".
I wrote down some thoughts on this in [1] - see the big red section
labeled TODO.
At the moment, I am still undecided about the best way here. Part of the
reason is that I myself do Basic scripts way too seldom to really judge
the expectations people could have here.
So, this is a call for feedback: If anybody feels comfortable with the
matter, then please tell me what you think would work best.
Imagine a macro configured to appear in the toolbar of a form, but
located (as macro) in the embodying database document. You want to
execute this macro from within the form, perhaps from within the
database document, and surely from within the Basic IDE during
developing it.
What's your expectations how ThisComponent should behave?
Any feedback is appreciated.
Thanks & Ciao
Frank
PS: That's the last issue which I need to solve and implement before I
can release a milestone build. See [2], milestone M1, for what you
can expect. Only if you're interested in getting your hands on some
brand-new stuff, of course ...
[1]http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents#Changes_with_Macros_in_Database_Documents
[2]http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents#Implementation_Milestones
Hi Frank,
I'm on the last week of Semester, so I MUST be brief.
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.
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. :-(
There are some other points:
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: in code I've seen from "common" users, they
tend to use ThisComponent to get a reference to the form-doc and its
logical forms and controls because it is *easier* (just think of a very
complex logical forms hierarchy of forms-subforms: the user will need to
query for the supported service of the object in order to know if
getParent() returns the form document, the logical forms container, or a
logical form). In this case, the user is "used" to ThisComponent: it is
the easier way s/he has to get a reference to the form document.
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.
If I want a reference to the model I must load it (using UCB or the
XComponentLoader at the DocumentContainer).
Now that the DatabaseDocument will participate in this macro-world,
shouldn't htere be a more straight-forward way to go form one model to
the other?
My answer: :-(
I will have to think it deeper (I will start on Monday, that I'm on
holidays!)
Regards,
Ariel.
--
Ariel Constenla-Haile
La Plata, Argentina
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.arielconstenlahaile.com.ar/ooo/
"Aus der Kriegsschule des Lebens
- Was mich nicht umbringt,
macht mich härter."
Nietzsche Götzendämmerung, Sprüche und Pfeile, 8.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
