summaryrefslogtreecommitdiff
path: root/udkapi
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2013-01-30 17:46:38 +0100
committerStephan Bergmann <sbergman@redhat.com>2013-01-30 17:46:38 +0100
commit2356a480fea6cac8cccaae85c9a2b6a312a9048c (patch)
treeb5e8220627dbb37a4389625372ae8521d1f225f5 /udkapi
parent0bfa66cdf21fed70828e778c99161bc9005d0457 (diff)
API CHANGE: Make TypeDescriptionManager/Provider more consistent
...by letting their getByHierarchicalName methods return information about UNO constants as X(Constant)TypeDescription values, just as for (alomst -- see the odd enum member case) all other entities. This will make future changes in this area easier. The only affected client I could find so far is the core reflection service, but there might be more that I overlooked. Change-Id: I6731f2914773d49e33eeaec6e256ff2e5409ad2d
Diffstat (limited to 'udkapi')
-rw-r--r--udkapi/com/sun/star/reflection/TypeDescriptionManager.idl16
-rw-r--r--udkapi/com/sun/star/reflection/TypeDescriptionProvider.idl13
2 files changed, 20 insertions, 9 deletions
diff --git a/udkapi/com/sun/star/reflection/TypeDescriptionManager.idl b/udkapi/com/sun/star/reflection/TypeDescriptionManager.idl
index 597dda266ceb..467047a61e6b 100644
--- a/udkapi/com/sun/star/reflection/TypeDescriptionManager.idl
+++ b/udkapi/com/sun/star/reflection/TypeDescriptionManager.idl
@@ -47,9 +47,18 @@ published service TypeDescriptionManager
{
/** Interface to retrieve type descriptions.
+ In addition to the semantics specified for the corresponding interface
+ of the <type>TypeDescriptionProvider</type> service (which changed
+ slightly for LibreOffice&nbsp;4.1; see there), this interface allows to
+ retrieve the following entities:
<ul>
- <li>Names are given in dotted notation, for example
- <code>"com.sun.star.uno.XInterface"</code>.</li>
+ <li>The simple types are accessible via <code>"void"</code>,
+ <code>"boolean"</code>, <code>"byte"</code>, <code>"short"</code>,
+ <code>"unsigned short"</code>, <code>"long"</code>, <code>"unsigned
+ long"</code>, <code>"hyper"</code>, <code>"unsigned hyper"</code>,
+ <code>"float"</code>, <code>"double"</code>, <code>"char"</code>,
+ <code>"string"</code>, <code>"type"</code>, and
+ <code>"any"</code>.</li>
<li>Sequence types are accessible via
<code>"[]<var>ComponentType</var>"</code></li>
@@ -63,9 +72,6 @@ published service TypeDescriptionManager
<code>"<var>InterfaceType</var>::<var>Member</var>"</code>.</li>
</ul>
- <p>The returned values are of interface type
- <type>XTypeDescription</type>.</p>
-
<p>Even though the name of this interface suggests that the used type
names are hierarchic, this need not be the case. (For example, consider
the names of instantiated polymorphic struct types, like
diff --git a/udkapi/com/sun/star/reflection/TypeDescriptionProvider.idl b/udkapi/com/sun/star/reflection/TypeDescriptionProvider.idl
index 672274b8d163..af84f3cff577 100644
--- a/udkapi/com/sun/star/reflection/TypeDescriptionProvider.idl
+++ b/udkapi/com/sun/star/reflection/TypeDescriptionProvider.idl
@@ -39,11 +39,16 @@ published service TypeDescriptionProvider
/** Interface to retrieve type descriptions.
<p>Names are given in dotted notation, for example
- <code>"com.sun.star.uno.XInterface"</code>. The returned values are of
- interface type <type>XTypeDescription</type>.</p>
+ <code>"com.sun.star.uno.XInterface"</code>.</p>
- <p>Even though the name of this interface suggests that the used type
- names are hierarchic, this need not be the case.</p>
+ </p>The returned values are generally non-null references of type
+ <type>XTypeDescription</type>. However, before LibreOffice&nbsp;4.1,
+ the value returned for a UNO constant was the value of the constant,
+ rather than a reference to an <type>XConstantTypeDescription</type>
+ object. (It also appears that some implementations return values for
+ individual UNO enum members, e.g.
+ <code>"com.sun.star.uno.TypeClass.VOID"</code>, though this is probably
+ best treated as an implementation obscurity.)</p>
*/
interface com::sun::star::container::XHierarchicalNameAccess;