Having serious issues with Lazarus and OpenOffice COM on win32

[snorkel]

I have been trying to port some Delphi code to windows and I have it all running, but am running into some
issues with OpenOffice.
The code works fine on delphi, the problem appears to be a issue with variant arrays and strings.

For example:

This does not work and openoffice can't find the file:
fDocument.StoreToURL('file:///'+ StringReplace(FileName, '\', '/', [rfIgnoreCase, rfReplaceAll]), wProperties);

however this does work:
fDocument.StoreToURL('file:///C:/Users/20659/Desktop/junk0/Rpt.pdf', wProperties);

I tried converting the variable version to UTF and Ansistring, but it simply does not work if the string has any parts that are from a
string var.

I then tried this:

var
   url:string;

url:= UTF8toAnsi(format('file:///%s',[StringReplace(FileName, '\', '/', [rfReplaceAll,rfIgnoreCase])]));

still bombs out.

The other isssue is with VarArrayCreate
for example:

var

   wProperties : Variant;

        wProperties := VarArrayCreate([0, 0], varVariant);
        wProperties[0] := MakePropertyValue('Hidden', True);  //this tells open office to not display a window when opening the doc

fDocument := fDesktop.loadComponentFromURL(''file:///C:/Users/20659/Desktop/junk0/NJMoOutsourcingRpt.xls'', '_blank', 0, wProperties);

OpenOffice simply does not like the VarArray created by FP/Lazarus and when the doc loads it ignores the wProperties sent as the last arg.

I am using version 0.9.30.2 from Nov 2011.  I am going to try one of the slightly newer daily snapshots with FP 2.6 and see if it's any better.
I also have the compiler switch set for Delphi Mode.

[ludob]

The compiler has made a lot of progress in COM support. So, yes, use 2.6.

Regarding strings, com uses BSTR which is compatible with fpc WideString. I don't know the prototypes used for the functions you mention but if they use variant, opposed to OleVariant, then the compiler will cast a string to a variant with subtype varstring which can not be marshaled by COM. Cast to widestring before passing it on to fDocument.StoreToURL or use var url:WideString;

Regarding varArrayCreate, fpc creates a COM compatible SafeArray (2.6 does, can't speak for earlier versions). I guess the problem is again a string vs. widestring issue. If you use the code for MakePropertyValue found here http://www.oooforum.org/forum/viewtopic.phtml?t=22344 then you are exactly in the case I described above (string assigned to variant). Modify the function to use widestring and OleVariant.

[snorkel]

Thanks for the info, I will try it out and report back my results.

Thanks again :-)

Snorkel

[Bart]

IIRC COM expects widestrings, so try explicitely using widestrings in your call (this is/was not automagically done by the compiler).

This would also explain why a hardcodes string constant works (because here the compiler assumes it is widestring).

Bart

[marcov]

It might also help to know which Delphi you are comparing with (specially wrt Bart's remark about widestrings)

[snorkel]

Thanks for the help guys, I made the changes to widestring and olevariant and it works fine now.
The original project was in Delphi XE2 32bit.

Thanks again for the help.

[marcov]

Thanks for the help guys, I made the changes to widestring and olevariant and it works fine now.
The original project was in Delphi XE2 32bit.

(since D2009, the default "string" is unicodestring, which is like widestring)
 

[ludob]

Thanks for the help guys, I made the changes to widestring and olevariant and it works fine now.
The original project was in Delphi XE2 32bit.

(since D2009, the default "string" is unicodestring, which is like widestring)
 

IIRC D6 had already variant to olevariant assignment routines that converted non automatable variant types to automatable ones, if possible. This allowed for mixing variants and olevariants and made the string/widestring issue transparent. The compiler did the cast to olevariant silently when using COM binding. I remember having seen run-time conversion errors with (custom?) variant types that couldn't be transformed to automatable ones.