-
Notifications
You must be signed in to change notification settings - Fork 499
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for creating collections #91
Comments
This depends on #81 |
Is there any workaround for this? I am trying to create a Ideally I would like to call |
As a workaround, you can create a WinRT component with C++/WinRT that creates and returns the collection and then call that from Rust. You can even just have a component that returns an empty collection that you can then populate using Rust. |
Hey @kennykerr, is this still a current workaround? Just hit this myself, needing an |
Yes, this is still blocked on #81 where I need to add support to implement generic interfaces. Right now, the |
Hey @kennykerr , is this still blocked? #81 is now closed. Granted, it did spin off a few other issues. I just need some way to pass an IIterable of HSTRINGs from Rust to wintrt. I'm hoping a year of progress has yielded at least a work around at this point that doesn't involve C++. |
Had the same issue,, I need to create IVector in rust in order to make it into
|
Yes, there's been some progress here. You can now implement the collection interfaces in Rust. This issue remains open because I haven't yet published a stock implementation, such as cppwinrt's https://github.com/microsoft/windows-rs/tree/master/crates/tests/implement/tests |
@tangp3 The core idea behind this revolves around the fact that the Windows Runtime provides a language-agnostic ABI. A Windows Runtime Components can be authored using any of the supported WinRT programming languages, and consumed from code written in any of the supported languages. The workaround described takes advantage of this by creating a Windows Runtime Component using C++/WinRT that exposes a factory method (e.g. a Rust code can now import this Windows Runtime Component and use its functionality to obtain an empty Authoring support for Windows Runtime Types in Rust has come a long way, and the |
Any update on this I'm having some issues trying to pass input params that match these traits. ::windows::core::InParam<super::super::Foundation::Collections::IIterable<::windows::core::HSTRING>> Using the example from https://github.com/microsoft/windows-rs/blob/master/crates/tests/implement/tests/into_impl.rs I was able to get an instance of Iterable<HSTRING> But I'm too dumb to implement the into |
You should be able to pass a reference as follows: let strings: IIterable<HSTRING> = ...
SomeMethod(&strings)?; |
I end up with a compiler error.
I'm trying to call these two functions.
Since I will have to implement Is there any ETA on the collections being completed? |
Not ETA, but I'm working on component authoring support at the moment and collection support is an important part of that. |
Good news, I was able to address some longstanding perquisites and started working on stock collections. For example, you will soon be able to write something like this: let able = IIterable::<i32>::try_from(vec![1, 2, 3])?; I should have these stock collections available soon. |
That was a busy week and concludes my work on WinRT collections for the time being. #2346, #2350, and #2353 cover the majority of cases where you'd need to create a collection to pass some data to an API. And these implementations are entirely thread safe! I'll leave the implementation of mutable WinRT collections for the time being as that is far less important outside of component authors and even then, APIs should prefer immutable collections. If you need to implement Sorry it took so long, but that was a mountain of work! 🥲 |
Many APIs assume the caller will provide a collection of values. This should integrate with
winrt::Param
to allow regular Rust collections and iterators to bind to WinRT input parameters of WinRT collection types.The text was updated successfully, but these errors were encountered: