Skip to content

W
wpf

dotNET Platform / wpf
11 个月 前同步成功

通知 1
Star 1
Fork 0
W
wpf

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 30 10月, 2019 1 次提交
  3. 29 10月, 2019 2 次提交
  5. 28 10月, 2019 2 次提交
  7. 27 10月, 2019 2 次提交
  9. 26 10月, 2019 2 次提交
  11. 25 10月, 2019 6 次提交
  13. 24 10月, 2019 4 次提交
    • D
      Update dependencies from... · 54470583
      由 dotnet-maestro[bot] 提交于 
      Update dependencies from https://dev.azure.com/dnceng/internal/_git/dotnet-wpf-int build 20191023.12 (#2109)

- Microsoft.DotNet.Wpf.DncEng - 5.0.0-alpha1.19523.12
      54470583
    • D
      Update dependencies from https://github.com/dotnet/arcade build 20191023.3 (#2108) · c815a826
      由 dotnet-maestro[bot] 提交于 
      - Microsoft.DotNet.ApiCompat - 5.0.0-beta.19523.3
- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19523.3
- Microsoft.DotNet.CodeAnalysis - 5.0.0-beta.19523.3
- Microsoft.DotNet.GenAPI - 5.0.0-beta.19523.3
- Microsoft.DotNet.Helix.Sdk - 5.0.0-beta.19523.3
      c815a826
    • V
      When an `HwndHost `receives `SourceChanged `event, it goes through... · 44a96d01
      由 Vatsan Madhavan 提交于 
      When an `HwndHost `receives `SourceChanged `event, it goes through `BuildOrReparentWindow`. When the hosted window is invisible, it is usually reparented under a temporary windows maintained by WPF in the `SystemResources `class, until later on the window can be rebuilt and parented back to a valid parent.

There is a latent bug in this logic where in `NULL ` `HWND's `are attempted to be parented to `SystemResources `managed temporary windows. This bug goes back quite a while (.NET 4.5 likely). WPF seems to ignore the return value from `kernel32!SetParent` and not deal with this failure. This has not been a crashing failure until now.

Starting .NET 4.8, there have been some changes to this codepath that has resulted in the current bug becoming a crash. In addition to calling `kernel32!SetParent` on a `NULL` `HWND`, WPF attempts to obtain a DPI-specific parking-window. This process of querying a DPI-specific parking window fails because WPF is unable to use the `DPI_AWARENESS_CONTEXT` value returned by the system for `(HWND)nullptr`.

The only necessary part of this fix is in `HwndHost`: WPF should not attempt to reparent the hosted window under a parking-window if the hosted window is `(HWND)nullptr`. This only requires a simple check : `else if (_hwnd.Handle != IntPtr.Zero)`). All other changes in `SystemResources` and `HwndHost` are defensive improvements.

`SystemResources.EnsureResourceChangeListener(HwndDpiInfo)` can attempt to create a parking-window corresponding to `DPI_AWARENESS_CONTEXT_VALUE` that is invalid/meaningless. This should not be allowed. A few additional checks are added to ensure this. Further, `GetDpiAwarenessCompatibleNotificationWindow` is augmented to be more defensive.

Also, variant of `EnsureResourceChangeListener`  is dead code - it is being removed.

If for some unknown reason `SystemResources.GetDpiAwarenessCompatibleNotificationWindow`  fails and returns `null` to `HwndHost.BuildOrReparentWindow`, WPF will fail to reparent the hosted window, and it will be 'lost'. This seems very unlikely - I have added a Trace to ensure that we can debug this situation if it does occur.
      44a96d01
    • V
      As part of a previous fix (that shipped originally as part of .NET 4.8 in), a... · 0437c64a
      由 Vatsan Madhavan 提交于 
      As part of a previous fix (that shipped originally as part of .NET 4.8 in), a change was made to `Popup` that involved the destruction and recreation of the underlying `HWND`. This was done to ensure that the `HWND` was always created with the correct monitor (~=DPI) affinity.

In order to acheive this, `DestroyWindow()` and `BuildWindow()` - private methods in `Popup` - were used.

We are finding that `DestroyWindow()` has side-effects that can lead to incorrect behavior. The incorrect beahvior works as follows:

  - The call into `Popup.CreateWindow` is usually a consequence `Popup.IsOpenChanged` (`false -> true`)
  - Within `Popup.CreateWindow`, `DestroyWindow()` is called (when high-dpi mode is detected).
  - `DestroyWindow()` destroys the underlying `HWND`, releases the capture, raises the *OnClosed* event and clears the placement-target.
    - At the end of `DestroyWindow()`, we get `IsOpen == false`.
  - After `DestroyWindow()`, we call into `BuildWindow()` and `CreateNewPopupRoot()` etc., which go on to build the `Popup` again (and also instnatiate a new `HWND`).
    - Unfortunately, there is no mechanism here for resetting `IsOpen` back to `true` (without also leading to an undesirable infinite-recursion that calls back into `CreateWindow`).

If these calls to show the context-menu arise from `ContextMenu.OnIsOpenChanged`, and flow through `ContextMenu.HookupParentPopup -> Popup.CreateRootPopup`, then `IsOpen` gets reset (there is a direct call into `SetBinding(IsOpenProperty)`, in `Popup.CreateRootPopupInternal`) and the popup is shown correctly. Until then, the context-menu is "stuck" not being able to be shown.

The solution is to stop using `DestroyWindow()` as-is, which does more than what we need for it to accomplish. Our original intent in calling `DestroyWindow()` was simply destroy and recreate the `HWND`. This fix refactors `DestroyWindow()` to suit this need and uses the newly introduced `DestroyWindowImpl()` to destroy the `HWND`, and then recreate just that. The rest of the state is retained intact, and the `Popup/ContextMenu` continues to function well as before.
      0437c64a
  15. 23 10月, 2019 10 次提交
  17. 22 10月, 2019 3 次提交
  19. 21 10月, 2019 1 次提交
  21. 20 10月, 2019 1 次提交
  23. 19 10月, 2019 4 次提交
  25. 18 10月, 2019 2 次提交
    • D
      Update dependencies from https://github.com/dotnet/arcade build 20191017.8 (#2064) · 5c48a420
      由 dotnet-maestro[bot] 提交于 
      - Microsoft.DotNet.ApiCompat - 5.0.0-beta.19517.8
- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19517.8
- Microsoft.DotNet.CodeAnalysis - 5.0.0-beta.19517.8
- Microsoft.DotNet.GenAPI - 5.0.0-beta.19517.8
- Microsoft.DotNet.Helix.Sdk - 5.0.0-beta.19517.8
      5c48a420
    • D
      [master] Update dependencies from dotnet/arcade (#2050) · fb5c3384
      由 dotnet-maestro[bot] 提交于 
      * Update dependencies from https://github.com/dotnet/arcade build 20191015.1

- Microsoft.DotNet.ApiCompat - 5.0.0-beta.19515.1
- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19515.1
- Microsoft.DotNet.CodeAnalysis - 5.0.0-beta.19515.1
- Microsoft.DotNet.GenAPI - 5.0.0-beta.19515.1
- Microsoft.DotNet.Helix.Sdk - 5.0.0-beta.19515.1

* Fix configure-toolset.ps1 to ensure the existence of the properties variable.

* Fixing scope and adding comment

* Update dependencies from https://github.com/dotnet/arcade build 20191015.2

- Microsoft.DotNet.ApiCompat - 5.0.0-beta.19515.2
- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19515.2
- Microsoft.DotNet.CodeAnalysis - 5.0.0-beta.19515.2
- Microsoft.DotNet.GenAPI - 5.0.0-beta.19515.2
- Microsoft.DotNet.Helix.Sdk - 5.0.0-beta.19515.2

* Adding workaround for https://github.com/dotnet/arcade/pull/4062

* Removing workaround for https://github.com/dotnet/arcade/pull/4062 as a fix has been affected in Arcade

* Update dependencies from https://github.com/dotnet/arcade build 20191017.7

- Microsoft.DotNet.ApiCompat - 5.0.0-beta.19517.7
- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19517.7
- Microsoft.DotNet.CodeAnalysis - 5.0.0-beta.19517.7
- Microsoft.DotNet.GenAPI - 5.0.0-beta.19517.7
- Microsoft.DotNet.Helix.Sdk - 5.0.0-beta.19517.7
      fb5c3384