[api-dev] use of css.container.EnumerableMap

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[api-dev] use of css.container.EnumerableMap

Paolo Mantovani
Hi,

after many years, ooo api users have finally got a concrete generic
implementation of an "associative array" or "Lookup table" or
"dictionary list"

That's great! this powerful service could greatly simplify the
development of macros / extension
but......

unfortunately the implementation is so  complicated and counterintuitive
that nobody will use it.

Of course I'm able to use it even in basic, but how can I explain it to
a novice that needs to translate from VBA a macro that uses VBA collections?
(however a starbasic example would be grateful)


The new uno service needs initialization, not fully supported in starbasic
The new uno service needs two parameters "UNO Type" a sort of object
very complex and abstract for a novice not expert in OOP (for example
99% of macro writers)

This kind of situations tends to discourage anybody that would like to
migrate but is afraid of loosing his/her skills

regards
Paolo Mantovani

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] use of css.container.EnumerableMap

Ariel Constenla-Haile
Hello Paolo,

On Saturday 18 December 2010, 11:00, Paolo Mantovani wrote:

> Hi,
>
> after many years, ooo api users have finally got a concrete generic
> implementation of an "associative array" or "Lookup table" or
> "dictionary list"
>
> That's great! this powerful service could greatly simplify the
> development of macros / extension
> but......
>
> unfortunately the implementation is so  complicated and counterintuitive
> that nobody will use it.
>
> Of course I'm able to use it even in basic, but how can I explain it to
> a novice that needs to translate from VBA a macro that uses VBA
> collections? (however a starbasic example would be grateful)
>
>
> The new uno service needs initialization, not fully supported in starbasic
 css.container.EnumerableMap is a new-style service, with constructors, and
AFAIK, new-style service constructors are now (I don't recall since when)
supported in OOo Basic; did you try to use the constructors directly?

> The new uno service needs two parameters "UNO Type" a sort of object
> very complex and abstract for a novice not expert in OOP (for example
> 99% of macro writers)

I wonder how you get that to work in Basic.
AFAIK UNO type is mapped to com.sun.star.reflection.XIdlClass
vid
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Basic/Mapping_of_Simple_Types

so I thought I needed to use reflection
http://api.openoffice.org/docs/common/ref/com/sun/star/reflection/XIdlReflection.html#getType

But passing a com.sun.star.reflection.XIdlClass to the constructors does not
work.

Sub Test_1
        Dim aData(4)
        aData(0) = Array(1,"Enero")
        aData(1) = Array(2,"Febrero")
        aData(2) = Array(3,"Marzo")
        aData(3) = Array(4,"Abril")
        aData(4) = Array(5,"Mayo")

        Dim oReflection
        oReflection = CreateUnoService("com.sun.star.reflection.CoreReflection")
       
        Dim aKeyType, aValueType
        aKeyType = oReflection.getType(aData(0)(0))
        aValueType = oReflection.getType(aData(0)(1))
       
        Dim aMap
        aMap = com.sun.star.container.EnumerableMap.create(aKeyType,aValueType)

        Dim aPair
        For Each aPair In aData
                aMap.put( aPair(0), aPair(1) )
        Next
               
        oReflection.dispose()
End Sub


it fails with the exception from
http://svn.services.openoffice.org/opengrok/xref/DEV300_m95/comphelper/source/container/enumerablemap.cxx#534

Then I tried the CreateUnoValue, with no luck...

Sub Test_2
        Dim aData(4)
        aData(0) = Array(1,"Enero")
        aData(1) = Array(2,"Febrero")
        aData(2) = Array(3,"Marzo")
        aData(3) = Array(4,"Abril")
        aData(4) = Array(5,"Mayo")

        Dim oReflection
        oReflection = CreateUnoService("com.sun.star.reflection.CoreReflection")
       
        Dim aKeyType, aValueType
        aKeyType = oReflection.getType(aData(0)(0))
        aValueType = oReflection.getType(aData(0)(1))
       
        Dim aArgs(1)
        aArgs(0) = CreateUnoValue("type",aKeyType)
        aArgs(1) = CreateUnoValue("type",aValueType)
       
        Dim aMap
        aMap = com.sun.star.container.EnumerableMap.create(aKeyType,aValueType)
        'aMap =
GetDefaultContext().getServiceManager().createInstanceWithArgumentsAndContext(_
        ' "com.sun.star.container.EnumerableMap",aArgs,
GetDefaultContext())

        Dim aPair
        For Each aPair In aData
                aMap.put( aPair(0), aPair(1) )
        Next
               
        oReflection.dispose()
End Sub

Here CreateUnoValue("type",aKeyType) fails.

> This kind of situations tends to discourage anybody that would like to
> migrate but is afraid of loosing his/her skills

IMHO the wrong choice was to use the UNO type instead of
com.sun.star.uno.TypeClass.
With TypeClass and the support for new-style service constructor, it could
have been as simple as:

        Dim aMap        
        aMap = com.sun.star.container.EnumerableMap.create(_
                        com.sun.star.uno.TypeClass.SHORT,_
                        com.sun.star.uno.TypeClass.STRING)

In Java this look also a little complicated:


    public static void main(String[] args) {
        try {
            int bound = 5000;
            Pair[] data = new Pair[bound];
            for ( int i = 0; i < bound; i++) {
                data[i] = new Pair(Integer.valueOf(i+1), String.valueOf(i+1));
            }

            // get the remote office component context
            XComponentContext xContext = Bootstrap.bootstrap();
            if (xContext != null) {
                XEnumerableMap aMap = EnumerableMap.create(
                        xContext,
                        AnyConverter.getType(data[0].First),
                        AnyConverter.getType(data[0].Second));
                for (Pair pair : data) {
                    aMap.put(pair.First, pair.Second);
                }

                XEnumeration xEnumeration =
aMap.createElementEnumeration(false);
                while (xEnumeration.hasMoreElements()) {
                    Object elem = xEnumeration.nextElement();
                    Pair pair = (Pair) ( (Any)elem ).getObject();
                    System.out.printf("%d - %s\n", pair.First, pair.Second);
                }
            }
        }
        catch (java.lang.Exception e){
            e.printStackTrace();
        }
        finally {
            System.exit( 0 );
        }
    }


Regards
--
Ariel Constenla-Haile
La Plata, Argentina

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] use of css.container.EnumerableMap

Ariel Constenla-Haile
On Saturday 18 December 2010, 21:34:00, Ariel Constenla-Haile wrote:
> IMHO the wrong choice was to use the UNO type instead of
> com.sun.star.uno.TypeClass.
> With TypeClass and the support for new-style service constructor, it could
> have been as simple as:
>
>         Dim aMap
>         aMap = com.sun.star.container.EnumerableMap.create(_
>                         com.sun.star.uno.TypeClass.SHORT,_
>                         com.sun.star.uno.TypeClass.STRING)

looking at
http://api.openoffice.org/docs/common/ref/com/sun/star/container/EnumerableMap.html
I see this won't work, because the EnumerableMap also takes other types than
simple ones, like ENUM and INTERFACE; sure in this cases the UNO type is need
and the uno.TypeClass is not enough.

Regards
--
Ariel Constenla-Haile
La Plata, Argentina

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] use of css.container.EnumerableMap

Bernard Marcelly
I fully agree with Paolo, this kind of API is a complex solution to a simple need.

I tried to make it work like this:

Dim keyType As Object, valueType As Object, reflect As Object

reflect = CreateUnoService("com.sun.star.reflection.CoreReflection")
keyType = reflect.forName("string")
valueType = reflect.forName("long")
enuMap = com.sun.star.container.EnumerableMap.create(keyType, valueType)
' --> error : com.sun.star.uno.Type expected.

If you look at the mapping of simple types for Basic in the Dev'Guide
<http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Basic/Mapping_of_Simple_Types>
you see that the UNO "type" is mapped in Basic to com.sun.star.reflection.XIdlClass
So my code (and yours) should be accepted.

Regards
   Bernard

Message de Ariel Constenla-Haile  date 2010-12-19 02:00 :

> On Saturday 18 December 2010, 21:34:00, Ariel Constenla-Haile wrote:
>> IMHO the wrong choice was to use the UNO type instead of
>> com.sun.star.uno.TypeClass.
>> With TypeClass and the support for new-style service constructor, it could
>> have been as simple as:
>>
>>          Dim aMap
>>          aMap = com.sun.star.container.EnumerableMap.create(_
>>                          com.sun.star.uno.TypeClass.SHORT,_
>>                          com.sun.star.uno.TypeClass.STRING)
>
> looking at
> http://api.openoffice.org/docs/common/ref/com/sun/star/container/EnumerableMap.html
> I see this won't work, because the EnumerableMap also takes other types than
> simple ones, like ENUM and INTERFACE; sure in this cases the UNO type is need
> and the uno.TypeClass is not enough.
>
> Regards



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] use of css.container.EnumerableMap

Stephan Bergmann-2
On 12/19/10 08:39, Bernard Marcelly wrote:

> I tried to make it work like this:
>
> Dim keyType As Object, valueType As Object, reflect As Object
>
> reflect = CreateUnoService("com.sun.star.reflection.CoreReflection")
> keyType = reflect.forName("string")
> valueType = reflect.forName("long")
> enuMap = com.sun.star.container.EnumerableMap.create(keyType, valueType)
> ' --> error : com.sun.star.uno.Type expected.
>
> If you look at the mapping of simple types for Basic in the Dev'Guide
> <http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Basic/Mapping_of_Simple_Types>
>
> you see that the UNO "type" is mapped in Basic to
> com.sun.star.reflection.XIdlClass
> So my code (and yours) should be accepted.

I'd suggest you file an issue for Basic.

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] use of css.container.EnumerableMap

Bernard Marcelly
Issue finally created (after servlet errors)
<http://www.openoffice.org/issues/show_bug.cgi?id=116184>

Regards
   Bernard

Message de Stephan Bergmann  date 2010-12-20 10:12 :

>
> On 12/19/10 08:39, Bernard Marcelly wrote:
>> I tried to make it work like this:
>>
>> Dim keyType As Object, valueType As Object, reflect As Object
>>
>> reflect = CreateUnoService("com.sun.star.reflection.CoreReflection")
>> keyType = reflect.forName("string")
>> valueType = reflect.forName("long")
>> enuMap = com.sun.star.container.EnumerableMap.create(keyType, valueType)
>> ' --> error : com.sun.star.uno.Type expected.
>>
>> If you look at the mapping of simple types for Basic in the Dev'Guide
>> <http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Basic/Mapping_of_Simple_Types>
>>
>>
>> you see that the UNO "type" is mapped in Basic to
>> com.sun.star.reflection.XIdlClass
>> So my code (and yours) should be accepted.
>
> I'd suggest you file an issue for Basic.
>
> -Stephan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] use of css.container.EnumerableMap

Paolo Mantovani
In reply to this post by Paolo Mantovani
Il 18/12/2010 15:00, Paolo Mantovani ha scritto:
[...]
> unfortunately the implementation is so complicated and counterintuitive
> that nobody will use it.
>
> Of course I'm able to use it even in basic,

ehmmm, clearly it was just my optimistic guess...
Thanks to Ariel, Bernard and Stephan for the responses


ciao
Paolo M


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] use of css.container.EnumerableMap

Frank Schönheit
In reply to this post by Paolo Mantovani
Hi Paolo,

> That's great! this powerful service could greatly simplify the
> development of macros / extension
> but......
> ...
> The new uno service needs two parameters "UNO Type" a sort of object
> very complex and abstract for a novice not expert in OOP (for example
> 99% of macro writers)

as I was the one who wrote this service (out of a particular need):
Sorry, I wasn't aware that Type is such a ... difficult thing in Basic.
I'll keep that in mind for the next API I design :-\

Ciao
Frank

--
ORACLE
Frank Schönheit | Software Engineer | [hidden email]
Oracle Office Productivity: http://www.oracle.com/office

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] use of css.container.EnumerableMap

Paolo Mantovani
Hi Frank,

Il 21/12/2010 10:25, Frank Schönheit ha scritto:
> Hi Paolo,
[...]
> as I was the one who wrote this service (out of a particular need):
> Sorry, I wasn't aware that Type is such a ... difficult thing in Basic.
> I'll keep that in mind for the next API I design :-\

Thank you, this is great!

In any case, I think that this kind of situation will be repeated in the
future.

The fact is that the usability and compatibility with StarBasic or other
scripting languages is not a requirement for new API. (AFAIK)

thank you
Paolo M

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] use of css.container.EnumerableMap

Frank Schönheit
Hi Paolo,

> In any case, I think that this kind of situation will be repeated in the
> future.
>
> The fact is that the usability and compatibility with StarBasic or other
> scripting languages is not a requirement for new API. (AFAIK)

There's a lot of things which are a requirement and nonetheless are
*not* fulfilled, so making something a requirement doesn't help in
itself. (take this as a philosophical note about The Great Whole Thing
or as a very specific note about our API, as you like.)

In this particular case, I even discussed the API in public (not sure at
the moment whether it was dev@api or interface-discuss@ooo, but I
definitely did, as I remember the pain to make it conform to all the
(rightful) requirements raised by different people). Sadly, nobody
caught this Type-problem - I'd bet this is pretty unknown to a lot of
people.

Ciao
Frank

--
ORACLE
Frank Schönheit | Software Engineer | [hidden email]
Oracle Office Productivity: http://www.oracle.com/office

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[api-dev] Enhancing StarBasic then ? (Re: [api-dev] use of css.container.EnumerableMap

Rony G. Flatscher
In reply to this post by Paolo Mantovani

On 22.12.2010 17:56, Paolo Mantovani wrote:

>
> Il 21/12/2010 10:25, Frank Schönheit ha scritto:
> [...]
>> as I was the one who wrote this service (out of a particular need):
>> Sorry, I wasn't aware that Type is such a ... difficult thing in Basic.
>> I'll keep that in mind for the next API I design :-\
>
> Thank you, this is great!
>
> In any case, I think that this kind of situation will be repeated in
> the future.
>
> The fact is that the usability and compatibility with StarBasic or
> other scripting languages is not a requirement for new API. (AFAIK)
If that is true, it is shooting in oneselves foot!
:(

So is that really true?
(It should be a *must* that non-OOo-core-developers are able to easily
create scripts and macros for remote-controlling an OOo installation!)

---

What about enhancing StarBasic then which would allow it to be fully
able to exploit any of the OOo services, no matter whether they are old
or newly developped services ?

---rony



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] Enhancing StarBasic then ? (Re: [api-dev] use of css.container.EnumerableMap

Frank Schönheit
Hi Rony,

>> The fact is that the usability and compatibility with StarBasic or
>> other scripting languages is not a requirement for new API. (AFAIK)
> If that is true, it is shooting in oneselves foot!
> :(
>
> So is that really true?

As said in my other reply, making something an requirement doesn't in
itself.

While having some kind of check list for API designs is a good thing,
what needs to be changed is the habit when designing APIs, the awareness
that our UNO API is the interface between OOo and it's clients, and thus
the importance of a well-designed API. Without this awareness, any check
list will be useless.

> What about enhancing StarBasic then which would allow it to be fully
> able to exploit any of the OOo services, no matter whether they are old
> or newly developped services ?

The concrete problem here is not with "old" vs. "new" services, in fact
(AFAIK) Basic nowadays supports new services pretty well (this wasn't
the case when they were introduced).

The problem here (as I understood it from the mails so far, I didn't try
myself) is the missing direct support of css.uno.Type in Basic.
I'm all in for enhancing this, but know too little details to judge
whether this is feasible and doable.

Ciao
Frank

--
ORACLE
Frank Schönheit | Software Engineer | [hidden email]
Oracle Office Productivity: http://www.oracle.com/office

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] use of css.container.EnumerableMap

Andreas Bregas
In reply to this post by Ariel Constenla-Haile
Hi Ariel,

after returning from Christmas holiday I've had a look at the problem
in the meantime. Thanks for your helpful test macros.


 >   css.container.EnumerableMap is a new-style service, with constructors, and
 > AFAIK, new-style service constructors are now (I don't recall since when)
 > supported in OOo Basic;

Since OOo 3.2, see
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Basic/Instantiating_UNO_Services#Using_new-style_service_constructors


 > AFAIK UNO type is mapped to com.sun.star.reflection.XIdlClass
 >
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Basic/Mapping_of_Simple_Types

The idea is correct but a look at the impletation shows that this map-
ping unfortunately only works in one direction. A UNO type coming in-
to Basic is mapped to XIdlClass but not the other way round. This is
wrong of course and I've decided to fix this immediately.


 > Dim aKeyType, aValueType
 > aKeyType = oReflection.getType(aData(0)(0))
 > aValueType = oReflection.getType(aData(0)(1))
 >
 > Dim aMap
 > aMap = com.sun.star.container.EnumerableMap.create(aKeyType,aValueType)

I see this as minimum solution as it just completes the type/XIdlClass
mapping, but it only works, if the target type is "type" and not if the
target type is "any", because then it cannot be decided if the "any" is
expected to be of type "type" or of type "XIdlClass".


 > Then I tried the CreateUnoValue, with no luck...
 >
 > aArgs(0) = CreateUnoValue("type",aKeyType)

So this also has to be supported to allow the macro programmer to force
type "type" for interfaces working with "any".


Problem: This is not very convenient, as the CoreReflection service
is needed to get XIdlClass. Probably in most cases the macro program-
mer knows in advance which types he wants to use. Each type has a
unique name, so it also makes sense to accept the type name, both in

     CreateUnoValue( "type", <UNO type name> )

as in

     MyUnoObj.MethodWithTypeParameter( <UNO type name> )


So also the following will be supported:

     aLongType = CreateUnoValue( "type", "long" )

or as in our case with fixed target type "type":

     aMap = com.sun.star.container.EnumerableMap.create( "long", "string" )


I think this is more elegant and matches the usual Basic philosophy
trying to perform sensible conversions automatically.

Regards

Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] Enhancing StarBasic then ? (Re: [api-dev] use of css.container.EnumerableMap

Andreas Bregas
In reply to this post by Rony G. Flatscher
Hi,

 >> Il 21/12/2010 10:25, Frank Schönheit ha scritto:
 >>> as I was the one who wrote this service (out of a particular need):
 >>> Sorry, I wasn't aware that Type is such a ... difficult thing in Basic.
 >>> I'll keep that in mind for the next API I design :-\

This is the wrong way, I think. Handling type correctly clearly is a
problem that has to be solved in Basic. Other problems in other lan-
guage bindings have to be solved there. Otherwise designing new API
would end up in painfully searching a way around all kind of obstac-
les that may be set by different language bindings. Not very nice. :-)


 >> The fact is that the usability and compatibility with StarBasic or
 >> other scripting languages is not a requirement for new API. (AFAIK)
 > If that is true, it is shooting in oneselves foot!
 > :(
 >
 > So is that really true?
 > (It should be a *must* that non-OOo-core-developers are able to easily
 > create scripts and macros for remote-controlling an OOo installation!)

+1


 > What about enhancing StarBasic then which would allow it to be fully
 > able to exploit any of the OOo services, no matter whether they are old
 > or newly developped services ?

+1, working on the type problem and nearly done already :-)

Regards

Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] use of css.container.EnumerableMap

Frank Schönheit
In reply to this post by Andreas Bregas
Hi Andreas,

> So also the following will be supported:
>
>      aLongType = CreateUnoValue( "type", "long" )
>
> or as in our case with fixed target type "type":
>
>      aMap = com.sun.star.container.EnumerableMap.create( "long", "string" )

That would be really useful - great idea!

Ciao
Frank

--
ORACLE
Frank Schönheit | Software Engineer | [hidden email]
Oracle Office Productivity: http://www.oracle.com/office

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] Enhancing StarBasic then ? (Re: [api-dev] use of css.container.EnumerableMap

Frank Schönheit
In reply to this post by Andreas Bregas
Hi Andreas,

>  >> Il 21/12/2010 10:25, Frank Schönheit ha scritto:
>  >>> as I was the one who wrote this service (out of a particular need):
>  >>> Sorry, I wasn't aware that Type is such a ... difficult thing in Basic.
>  >>> I'll keep that in mind for the next API I design :-\
>
> This is the wrong way, I think. Handling type correctly clearly is a
> problem that has to be solved in Basic. Other problems in other lan-
> guage bindings have to be solved there. Otherwise designing new API
> would end up in painfully searching a way around all kind of obstac-
> les that may be set by different language bindings. Not very nice. :-)

Sorry, I wasn't precise here: Of course the root cause should be fixed
in Basic's UNO binding (and I like your ideas you sketched in the other
mail). What I wanted to say is that I shall pay more attention to how
usable an API is in the different bindings. Usually, I only design the
API as such, but don't think about pitfalls of the various UNO bindings.
If I had, and if I had tried the API in Basic, the bugs in Basic's
binding would have been found earlier, and perhaps fixed before release
of the new API into the wild.

Ciao
Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] use of css.container.EnumerableMap

Paolo Mantovani
In reply to this post by Andreas Bregas
Il 05/01/2011 12:31, Andreas Bregas ha scritto:
[....]

> Problem: This is not very convenient, as the CoreReflection service
> is needed to get XIdlClass. Probably in most cases the macro program-
> mer knows in advance which types he wants to use. Each type has a
> unique name, so it also makes sense to accept the type name, both in
>
> CreateUnoValue( "type", <UNO type name> )
>
> as in
>
> MyUnoObj.MethodWithTypeParameter( <UNO type name> )
>
>
> So also the following will be supported:
>
> aLongType = CreateUnoValue( "type", "long" )
>
> or as in our case with fixed target type "type":
>
> aMap = com.sun.star.container.EnumerableMap.create( "long", "string" )
>
>
> I think this is more elegant and matches the usual Basic philosophy
> trying to perform sensible conversions automatically.

+1

Great enhancement, I like it

thanks
Paolo M

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]