Есть следующая задача.

Есть библиотека, реализующая COM интерфейс.
У него есть 1 метод и 2 свойства.

Вызов типа:

Отрабатывает.

Метод интерфейса формирует строку типа BYTE*.
(Собственно это строку мне и нужно оттуда получить.)

Свойство OLE объекта объявлено как "BSTR a".
(#typedef WCHAR *BSTR)

Передать в уникод строку поток байт просто так нельзя, поэтому строка байт переводится в BASE64, BASE64 строка приводится к уникоду и вроде как должна вернуться как значение свойства.
Вот тут и происходит облом. Я точно знаю, что метод отработал. Сформировал строку. Она была преобразована в BASE64 и так далее...
Но в момент:

sy-subrc я получаю 4. Тобишь ошибка чтения свойства...

Может кто-то сможет подсказать, что я делаю не так?

В общем, проблему решил, но несколько "нестандартно".

Сделал 2 свойства.
Длинна строки(изначально я ее знаю)
И 1 байт параметризованный.

Дальше так. Вызываю метод OLE, который формирует строку. Дальше считываю значение, содержащее длину строки.
А дальше в цикле по байту вытягиваю строку.


Работает это не быстро, но гарантированно.

[s]ЗЫ: Принимающая переменная должна быть типа X, в том случае, если принимать в xstring - придет два байта. Первый значащий, второй пустой(например FD00).[/s]
Обновления. Ошибся я. Не байт эта зараза возвращает, а integer... То есть, если в оригинале было 30, я в ABAPе получу 48... Сейчас буду думать дальше. Ну или просто приводить назад в шестнадцатиричное значение...

Если найду решение изначальной проблемы - отпишусь.

А какая общая длинна строки? Не больше 256?

Совершенно любая.

Может быть значения длиннее 256 байт не пролазят? Попробовать передавать не по 1 байту а по 64/128?

Вроде предпосылок нет... Как минимум не встречался где-то в описании с такими ограничениями.
Но это идея, можно попробовать.
Хотя с точки зрения прозрачности - более нагруженный код получится, а о производительности речь не идет. Операция не частая. Сейчас у меня отрабатывает за 3-5 секунд, так что не критично.

Здравствуйте, Вы случайно обращаетесь не к криптобиблиотеке?