*Hi all,*
Here’s a quick update outlining the progress from *Week 9* of the Rust–UNO
binding project.
Last week, I worked on handling *edge cases* in the generated code. I’ll
also summarize what we have been doing over the past weeks regarding the
generated code:
-
When calling *C++ logic via FFI*, we found that we must wrap it in *C
functions or C-compatible types* (e.g., structs, enums).
-
To address this, we relied on *XInterface* (the base interface for all
UNO interfaces). We pass it as a parameter, cast it to the required
interface, and then call the target method.
-
Since Rust *traits* cannot be directly used across FFI boundaries, we
always evaluate whether something can safely cross FFI before implementing
it.
-
For other *core UNO types*, we used their *internal pointers* to pass
values between Rust and C. We then cast those pointers to the corresponding
C++ types (e.g., rtl_uString and OUString).
-
As Rust does not support *inheritance for structs*, we handled this by
using *composition* in the parent struct instead.
Here’s an example of what we discussed:
```
/// FFI bridge for ooo.vba.excel.XRange::Address
rtl_uString* Address_(
XInterface* pInterface,
uno_Any* RowAbsolute,
uno_Any* ColumnAbsolute,
uno_Any* ReferenceStyle,
uno_Any* External,
uno_Any* RelativeTo
)
{
if (!pInterface)
return nullptr;
try
{
Reference<ooo::vba::excel::XRange> xInterface(pInterface,
UNO_QUERY_THROW);
auto result = xInterface->Address(
*reinterpret_cast<Any*>(RowAbsolute),
*reinterpret_cast<Any*>(ColumnAbsolute),
*reinterpret_cast<Any*>(ReferenceStyle),
*reinterpret_cast<Any*>(External),
*reinterpret_cast<Any*>(RelativeTo)
);
// Convert OUString result to rtl_uString*
return result.pData;
}
catch (const Exception& e)
{
SAL_WARN("codemaker.rustmaker", "Exception in FFI bridge function");
(void)e;
return nullptr;
}
}
```
*Next steps:*
-
Continue handling *edge cases* in the generated code.
-
Expand support for *core UNO types*.
Best,
Ali
