XboxGameBarWidget exposes an ElementTheme property and event for when it changes.

https://docs.microsoft.com/en-us/gaming/game-bar/api/xgb-widget#game-bar-state

That is correct - keeping in mind that it takes about a week for most users to get the update. If they seek it out in the store (check for updates) they can upgrade at will.

FYI - the 20.06 release date has been tentatively moved to 6/24 in order to work through a recently discovered issue. Please continue to hold any app submissions that depend on the 5.3 SDK until it has been released.

Sorry for the inconvenience.

FYI - the 20.06 release date has been tentatively moved to 6/24 in order to work through a recently discovered issue. Please continue to hold any app submissions that depend on the 5.3 SDK until it has been released.

Sorry for the inconvenience.

FYI - the 20.06 release date has been tentatively moved to 6/24 in order to work through a recently discovered issue. Please continue to hold any app submissions that depend on the 5.3 SDK until it has been released.

Sorry for the inconvenience.

FYI - the 20.06 release date has been tentatively moved to 6/24 in order to work through a recently discovered issue. Please continue to hold any app submissions that depend on the 5.3 SDK until it has been released.

Sorry for the inconvenience.

Newer versions of Game Bar will work with widgets that were built with older SDKs, but not the other way around. It's easier to build backwards compatibility against a known feature set, then try to support widgets from the future that may require functionality an older game bar can't support.

If you ship your widget with the new SDK before we release the new Game Bar, users with the old Game Bar will not be able to use your widget. When attempting to load the widget they will instead get text inside the frame instructing them to upgrade Game Bar, which will not be possible short of joining an insider flight ring.

So while nothing will catastrophically break, it will not work either. Our intent is for you to have the release SDK ahead of time so that you can start building and testing against it, but preferably wait until we ship the new Game Bar before you publish your own app.

What do you think of this? It's a policy that we're still working on, and would like feedback on. Alternately we could wait until Game Bar ships before releasing the updated nupkg.

We'll be addressing this in the next update, should be available early next week. VSO 26769630

Describe the bug If you have a pinned widget and Game Bar's display mode is currently PinnedOnly, calling TryResizeWindowAsync will resize the widget, but not the clipping region. As such, if the widget is made smaller, the now blank region will still not let you click through, and if you make the widget bigger, the expanded region is not visible.

To Reproduce

1. Have a widget which is pinnable and can call TryResizeWindowAsync.
2. Pin widget and close Game Bar.
3. Perform an action with it that will call "TryResizeWindowAsync".
4. If made smaller, try clicking a region where the widget used to occupy.

Expected behavior The expected behavior is that resizing my widget will result in the rendering and interactive region changing to that size, even when pinned. Currently it only behaves this way if Game Bar's Display Mode is Visible.

Screenshots

Desktop (please complete the following information):

• OS version: Windows 10 1909 (OS Build 18363.778)
• Game Bar version: 5.120.4062.0
• SDK version: XboxGameBar.5.1.200402003

Additional context There seems to be a related problem where sometimes if you hit "Restart" on "Something went wrong with this widget" while it's pinned, or when the widget enters that state after having been resized during running, the window position/size will change slightly, but the clipped region also remains the same, however I do not have reliable reproduction steps for this.

This issue is resolved in the current 20.06 flighting builds and will be available for GA in ~2 weeks. Closing this issue now, please reactivate or comment if you're still seeing the issue.

We're investigating this now.

Describe the bug Setting the Background Transparent doesn't apply to the widget in Game Bar

The Default System Performance Widget is actually Transparent, how is this achieved?

Closing this issue as the original is a feature in 20.06 and already in preview. For the latter I believe a new issue should be created and we will mark as feature request for consideration.

Did you add "uap3" to the top of your manifest? It's needed as both a namespace and in the IgnorableNamespaces section.

<Package xmlns="..."
         xmlns:mp="..."
         xmlns:uap="..."
         xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3"
         IgnorableNamespaces="uap mp uap3">

The last two lines are for when you're using the latest 5.3 pre-release SDK. Your Game Bar version is 5.1 so it's the release version. What version of the NuGet package / SDK are you using? With your version of Game Bar you should be using the latest release (5.1.200402003).

Did you step through your OnActivate and verify everything is being setup correctly there?

This issue is still active - we will continue to release updates prior to the 20.06 build being final.

Is your feature request related to a problem? Please describe. For a widget I'm working on, a common use for it will involve it being pinned over top of a game, but since widgets can't be transparent, the area taken up by our widget will completely obscure that area of the screen. Any attempt to adjust opacity of controls just reveals a white background.

Describe the solution you'd like The solution we would like to see is to let us have the option to remove the background for the frame so that we can have control over the transparency of our widget and its controls, like the Performance widget already does.

Describe alternatives you've considered We could not come up with any alternatives. Either the widget has transparency and doesn't obscure part of the screen, or it doesn't have transparency.

Additional context Example of the Performance widget's transparency.

We do know that the widget does not become a part of the Game Bar layout, and is instead a remote view. We confirmed that opacity changes in the Game Bar layout through debugging also affect the white background. Additionally we confirmed that our widget does not contain a background as part of it's layout that could explain the white background. This leads us to suspect that the remote view does not support an alpha channel.

Today we're publishing the prerelease version of the 20.06 release which includes support for transparency. Check out the changelog for more information, along with the accompanying documentation. The samples for this early look are in the origin/prerelease branch. Be sure to update your Game Bar build with the latest from the SDK flight ring.

React Native for Windows is a very active project which changes rapidly. We've experimented with it in the past and found it to have some threading issues that prevent it from working correctly in Game Bar. The project has also made an architectural decision to move to WinUI3 which Game Bar cannot currently host. We are working with the WinUI team to add the necessary support to enable its use, but there's currently no ETA.

We have a long term goal of supporting React Native in the future, but as of now we can't recommend it for widget development.

In the advanced samples provided ForegroundWorkHandler and XboxGameBarForegroundWorker classes are not found. Were they removed from the nuget package perhaps?

The change has been reverted. Closing this.

Thanks - will track for the 20.06 release. [VSO 26048604]

@dynamiquel we agree - in general users should have control over any additional capabilities a widget gains while running in Game Bar. Having some control of widget capabilities is part of the requirements for notifications.

This is a known limitation with WebView. At this time we don't support using a WebView in a widget. We're currently investigating support for the chromium based WebView2, but don't have an estimated timeline for when that might be available.

Yes, this is the same issue. Will update the title to reflect.

When using the default Visual Studio project template for a UWP C++/WinRT application you may find encounter linker errors. The errors indicate that they cannot recognize the version of C++/WinRT package that was installed.

To work around this, right click and your project and select Properties. Navigate to Configuration Properties -> Linker -> Input -> Additional Dependencies and add "OneCore.lib". Be sure to and save your changes.

Widget apps cannot specify they are multi-instance (desktop4:SupportsMultipleInstances). If they do it will cause Game Bar and Windows Explorer to crash. This issue does not prevent you from having multiple widgets on the same app. That scenario does not require the desktop4:SupportsMultipleInstances attribute to be set.

Closing a foreground instance of your app shuts down your app process. Since the foreground launch of your app and the Game Bar widget share the same process this also closes your Game Bar widget. We will provide guidance in the future on ways to deal with this correctly.

Known Issue: ComboBox controls may remain open over your application or desktop if Game Bar is dismissed. Close the list before closing Game Bar.

If the list is left open after dismissing Game Bar, simply re-open Game Bar and dismiss the control before dismissing it again.

We're evaluating how to enable this functionality, but haven't committed to a date for delivery.

We agree this is something widget developers will need to make there scenarios successful. We don't yet have a timeline for when we will delivery a notification mechanism.