WindowsAppSDK
WindowsAppSDK copied to clipboard
microsoft
How to use the WinRT API SystemTray class? When wasdk provide SystemTray API for desktop apps?
Describe the bug
How to use WinRT API SystemTray class? I found the official API document, but there are no version requirements and code examples of this API. May I ask how to use this API? In addition, when will the Windows app sdk provide a usable SystemTray API?
WinRT API SystemTray 类怎么使用，我找到了官方的API文档，但是没有该API的版本要求和代码示例，请问一下这个API该如何使用。除此之外，Windows app sdk什么时候能提供一个可用的SystemTray API呢？
https://learn.microsoft.com/zh-cn/uwp/api/windows.ui.viewmanagement.systemtray
Steps to reproduce the bug
See above
Expected behavior
See above
Screenshots
See above
NuGet package version
WinUI 3 - Windows App SDK 1.4.3: 1.4.231115000
Windows version
Windows 11 (22H2): Build 22621
Additional context
None
How did you manage to find that?
That runtime class isn't in the union metadata for the latest insider SDK. It isn't exposed in the SDK headers itself. What this means is that it is either an internal runtime class, it is a work in progress or it was abandoned but they never cleaned up the documentation. The fact that you can't get to this through the Windows.UI.ViewManagement namespace says a lot here. Either way, since it has GetForCurrentView and no constructor means that this would require an interop interface, so it would be unusable even if you found some way to get access to it.
Either way, I have no input on the notification API since I agree that Shell_NotifyIcon and related functionality isn't the easiest API to work with.
How did you manage to find that?
That runtime class isn't in the union metadata for the latest insider SDK. It isn't exposed in the SDK headers itself. What this means is that it is either an internal runtime class, it is a work in progress or it was abandoned but they never cleaned up the documentation. The fact that you can't get to this through the Windows.UI.ViewManagement namespace says a lot here. Either way, since it has GetForCurrentView and no constructor means that this would require an interop interface, so it would be unusable even if you found some way to get access to it.
Either way, I have no input on the notification API since I agree that Shell_NotifyIcon and related functionality isn't the easiest API to work with.
I found this API by accident. There is no direct link to this API in the official documentation, but I found this API when I tried to search for the GetForCurrentView method. After some discussion, we found that this API was added in the 17692 preview and removed in 17723, the specific reason is not known why, nor do we know what happened inside MS at that time. 我是在意外中找到了这个API。在官方文档中并没有直接的链接查看这个API的信息，我尝试搜索GetForCurrentView方法时发现了这个API。经过一番讨论，我们发现这个API是在17692预览版中添加了，在17723中移除了，具体原因不知道为什么，也不知道当时MS内部发生了什么事情。
https://martinsuchan.github.io/ApiPeek/Diffs/win10.17713.to.win10.17723.diff.html
https://martinsuchan.github.io/ApiPeek/Diffs/win10.17686.to.win10.17692.diff.html
@rkarman - this is https://task.ms/16666415 - should these docs be deleted [and the LCR bug taken]? cc @stevewhims
Adding @Karl-Bridge-Microsoft as writer-owner of the topic in question. This topic is being published because the content system knows about the API. Even if we deleted the authored content from the system, the system would still (I believe) publish a stub topic for the API (simply b/c the API exists). And in that case there'd be even less info in the topic than currently. So the real solution seems to be to remove the API from the platform. However, Karl will know more, and will be able to confirm/correct what I say above.
-Steve
@rkarman - this is https://task.ms/16666415 - should these docs be deleted [and the LCR bug taken]? cc @stevewhims
The "System Tray" API referenced on those pages was a Windows Mobile Phone API, it was deprecated along with the Windows Phone SDK for UWP. I.e. this API has no implementation on Windows Desktop, Xbox, HoloLens or IoT versions of UWP platforms. The interface itself has remained for compatibility reasons to not crash legacy apps/components that are no longer being updates/services. The interface cannot be removed without further work in those components, which is not something the owners of said components are willing to take on.
So, if the doc pages cannot be removed as long as the interface exists, can they at least be update to state that this API is obsolete and non-functional?
Thanks @rkarman! That's great info, and I feel confident adding it to the docs (even thought I'm not writer-owner for them). It turns out in fact that there were no authored topics for these APIs. The content publishing pipeline was simply automatically publishing empty stubs for the APIs just because the APIs exist. So in order to be able to add a deprecation notice, I had to create authored topics for the APIs. Anyway, that's done now, and published. I don't have a button here for closing the issue, but if somebody else could do that, that'd be great.
Thanks! -Steve