I'm trying to integrate OpenOffice in our software.
It can be done using com-handles, albeit in a limited way.
So I tried using real objects instead. I keep running into problems when using CAST however. Probably because of the UNO-structure-thingie, but I'm not sure.
I always get an "Invalid Cast"-error. However, passing the object to a procedure with an input parameter does work.
I've included an example to clarify my problem:
def var oStrap as XComponentContext no-undo.
def var oServ as XMultiServiceFactory no-undo.
def var oStrTmp as XMultiComponentFactory no-undo.
oStrap = uno.util.Bootstrap:bootstrap().
oStrTmp = oStrap:getServiceManager().
run pTest (input oStrTmp). /* OK */
oServ = cast(oStrTmp , XMultiServiceFactory). /* NOK */
def input param p as XMultiServiceFactory.
oServ = p.
The run pTest will work (I've made a complete working sample generating a spreadsheet).
The CAST will fail. I was hoping a class using methods would work in the same way as a procedure, but it does a check of it's types and generates the same error as a cast.
Any ideas why the CAST fails, but the procedure works? (If you want to test, you'd need to include the cli*-dll's into assemblies.xml)
Progress 101a & 102b (soon to be 11.??)
I guess 10.2a as 10.1a did not have access to .NET objects.
I remeber that there were issues on 10.1a with access to COM-Interop objects. What message does CAST give you?
Yes 10.2A, not 10.1A. My mistake...
But 10.2B gives the same error:
Invalid cast from System.Object to
unoidl.com.sun.star.lang.XMultiServiceFactory, cli_uretypes (12869)
The same cast in C# does work.
Did you try the latest 10.2B service pack? 07 when I am not mistaking?
OE 11.2.1 / Win7 x64
I was curious - and wanted to have a quick spin with OpenOffice - but was stopped in my tracks after a few minutes (excluding download time).
The cli_cppuhelper.dll is 'currently' (since 2010 it seems) broken and will only work on a 32-bit machine - see also 'new' bug for the other branch https://bugs.freedesktop.org/show_bug.cgi?id=61503
Just a heads up.
The dll is indeed a 32-bit version.
I believe it'll work correctly if you compile a 32-bit application.
At least for me that worked in Visual Studio.
My Progress did not pose any problems.
But I see you're using version 11. Perhaps there are more options concerning 32/64 bit in this version.
btw, I'm using the exact same OS. Also tested on a 32 bit XP.