Help with returning a string from a ComInterfaceImp subclass

I have an IDL function defined as:

 typedef [ptr, string] char line[16];
     HRESULT GetMark(
          [ out, retval, string ] char** returnVal
      );

DST generated this interface code

getMark
    "Answer the <String> result of invoking the GetMark() method of the COM
object."
    | answer |
    answer := (StructurePointer newNull: COMTaskMemory elementClass:
String).
    self GetMark: answer.
    ^answer asObject

Try as I might I can't get the ST method to work. The implementation code is

GetMark: returnVal
    | q |
    q := ....
    returnVal value: (q getMark).
    ^S_OK

When this executes it fails trying to cast the string into an integer in
retryDwordAtOffset: put:

I'm obviously doing something dumb, so could someone please set me on the
right track.

Cheers
Keith

Problem solved - I needed to convert the string answer to a BSTR

Keith

Keith

You wrote in message news:b9ns90$4ua$[hidden email]...
> Problem solved - I needed to convert the string answer to a BSTR

Be careful, that probably isn't right assuming that you are both
implementing and calling this interface (?), although you may "get away with
it". A BSTR would not be the right thing to return for the IDL you quoted.

Returning C strings through a COM interface is pretty unusual, not least
because it is tricky to get right, but also because it is not automation
compatible and AFAIK, not supported by VB clients. Are you sure the IDL is
right? If it has been decoded from a type library then sometimes it may not
be due to limitations in the type-library format, or a bug in the
type-library analyzer. You can eliminate the latter by comparing Dolphin's
IDL with that generated by OLEVIEW.

Anyway the IDL implies that a char** string is expected, i.e. a single-byte
ASCII string allocated by the callee from the COM task heap that will be
free'd by the caller (or the RPC layers if the caller and callee are in
separate processes). A BSTR is a type of Unicode (double-byte) string which
will be null-terminated, but which will also have a 32-bit length count in
the 4-bytes before the string data. BSTRs should always be allocated and
deallocated through SysAllocString/SysFreeString and friends. It so happens
that these use the standard COM task heap (i.e. the default process heap),
and so you will probably find it does not fault, but there will be a leak of
the four-bytes.

Regards

Blair