Hi there,
So - it seems the reason the python binding was crashing, is that most
objects would have the XInvocation2 interface[1] provided in some magic
way - but it seems that, the few classes that implement XInvocation[2]
don't get that - so well, we all crash:
Reference<XInvocation2> tmp_invocation (tmp_interface, UNO_QUERY);
..
self->members->xInvocation = tmp_invocation;
and later ...
Sequence<OUString> oo_member_list;
oo_member_list = me->members->xInvocation->getMemberNames ();
bang :-) (xInvocation will be null).
So - I just pushed a patch to at least throw a nice, helpful exception
for this.
Unfortunately - com.sun.star.resource.VclStringResourceLoader is one of
the few classes to do this cf. extensions/source/resource/resource.cxx
So - if we want to use this class from Python, we need to work out:
a) what the heck is going on in that resource.cxx class :-)
+ why is it implementing XInvocation - there seems to be
no really good reason for this.
+ particularly since getDefaultInvocation just returns
null always ;-)
b) should we just re-write it as a clean interface, instead of
this 'orrible mess ?
c) if so - we should unwind the mess in Wizards, explicitly
doing pointless lifting like:
final String IDString = (String)
xInvocation.invoke("getString", nIDArray, PointerArray, DummyArray);
I imagine.
Bjoern - perhaps you can look into that if this is a key class to be
using for the GSOC project ?
Thanks,
Michael.
[1] - udkapi/com/sun/star/script/XInvocation2
[2] - udkapi/com/sun/star/script/XInvocation1
--
michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
