Hi Stephan,
>>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.
okay, replace "interface/method pair" in my sentence with "way to
retrieve the attribute value". The concrete syntax for this might be
language-binding-dependent, but it's nonetheless less simple than just
(piding-something):
void propertyChanged( Source, Name )
{
currentValue = Source.getPropertyValue( Name );
}
But, well, probably you can hide the complexity of finding the right
attribute-getter behind reflection:
void attributeChanged( Source, Name )
{
currentValue = reflectionAdapter( Source ).getPropertyValue( Name );
}
Something like this.
Anyway, I surely don't insist on those NewValue/OldValue thing.
>>(We should switch to non-default mode then where idlc *does* complain).
>
> (Which we unfortunately cannot do easily for backwards-compatibility
> issues...)
Hmm. Can we switch to a slightly-non-default-mode which only finds those
identifiers, and behaves like in default mode for all other issues?
We could just change the (argument?) identifiers then which currently
already start with -. Or is renaming an argument identifier considered
incompatible?
>>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.
Okay.
Thanks & Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
