You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 2, 2021. It is now read-only.
In order to generate the correct code to deal with these types as parameters (e.g. CreateDispatcherQueueController), we need to be able to resolve those types. At the moment, these types are all interfaces or runtimeclasses, so we can work around the lack of a definition for now, and use other definitions
What's worse, is that for these APIs to be truly usable, the calling code needs to have some notion of a type definition. Right now, there is no such thing as win32::Windows::Foundation::IPropertyValue, and it seems unlikely to ever change - we already have a first-class projection of WinRT types in C++/WinRT.
So, we have three alternatives as I see it:
Interop with C++/WinRT, and perhaps even converge/merge with that projection. The lightest version would be when we encounter those types to generate the #include statements for the C++/WinRT headers - but this doesn't seem like a great user experience if the user doesn't know about nor wish to use C++/WinRT. So, this path strongly leads towards some sort of merge in our future.
Generate a minimal "Win32" version (i.e. pared-down) of the needed WinRT types, sort of how the official SDK refers to types in the ABI namespace.
Don't do much of anything at all, and leave these WinRT types as forward declarations only.
In the current metadata, we are seeing references to some WinRT types:
In order to generate the correct code to deal with these types as parameters (e.g. CreateDispatcherQueueController), we need to be able to resolve those types. At the moment, these types are all interfaces or runtimeclasses, so we can work around the lack of a definition for now, and use other definitions
What's worse, is that for these APIs to be truly usable, the calling code needs to have some notion of a type definition. Right now, there is no such thing as
win32::Windows::Foundation::IPropertyValue, and it seems unlikely to ever change - we already have a first-class projection of WinRT types in C++/WinRT.So, we have three alternatives as I see it:
#includestatements for the C++/WinRT headers - but this doesn't seem like a great user experience if the user doesn't know about nor wish to use C++/WinRT. So, this path strongly leads towards some sort of merge in our future.ABInamespace.