Frank Schönheit - Sun Microsystems Germany wrote:
Hi Stephan,
Just to clarify: "[attribute, bound]" is observable reflectively via
com.sun.star.reflection, and used by the C++/Java PropertySetMixin
helpers. I would strongly recommend to add "bound" to any attributes
for which a change-notification mechanism shall be supported, be it
XPropertySet, the proposed XAttributeChangeBroadcaster, or whatever.
But this cannot cover value changes by direct interface calls, can it?
IOW, if I call XFoo::setBar, then this will not be notified. Only
calling the reflection adapter's XPropertySet::setPropertyValue( "Bar",
<value> ) will be notified. Right?
I guess we are talking past each other here. All I wanted to say is:
If you design an interface attribute A for which you intend changes to
be notified (where both the way changes are caused and the way changes
are notified could be by whichever mechanism seems appropriate, be it
via a wrapping XPropertySet, via direct attribute access and the
proposed XAttributeChangeBroadcaster, via a mixture of the above, or
whatever), then add "bound" to the declaration.
To answer your specific question: Whether a direct change to an
interface property leads to a notification of registered
XPropertyChangeListeners depends on the object's implementation. (If
you use the C++/Java PropertySetMixin helpers in the object's
implementation, the notifications will take place.)
...don't want to restart the discussion that Old/NewValue are of no use
here (<http://www.openoffice.org/servlets/ReadMsg?list=dev&msgId=360257>)...
Hmm. Cross-reading this thread, I've got the impression that values
*could* be of use in some cases.
Also, in opposite to property sets, obtaining a value here is more
"complex" than for property sets. In the latter case you can just call
getPropertyValue, in the former you need to map the attribute name to
the proper interface/method pair.
How you access a UNO interface attribute is language-binding--specific;
the get/set pair of functions is a detail of the C++ language binding.
Ooops, you said you didn't want to start the discussion :)
Okay, can remove this.
interface XAttributeChangeListener
{
[oneway] void attributeChanged( [in] AttributeChangeEvent _Event );
"_Event" etc. are not valid UNOIDL identifiers (even though idlc
unfortunately does not complain in default mode); no leading
underscores, please.
(We should switch to non-default mode then where idlc *does* complain).
(Which we unfortunately cannot do easily for backwards-compatibility
issues...)
In the light of the above-mentioned thread: Should we remove the
[oneway] from the attributeChanged method?
Yes, in any case! [oneway] is a bad idea most of the time, anyway.
-Stephan
Thanks & Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
