WPF 使用 WindowChrome,在自定义窗口标题栏的同时最大程度保留原生窗口样式(类似 UWP/Chrome)

WPF 使用 WindowChrome,在自定义窗口标题栏的同时最大程度保留原生窗口样式(类似 UWP/Chrome)

发布于 2018-07-12 07:57 更新于 2018-09-05 05:46

WPF 自定义窗口样式有多种方式,不过基本核心实现都是在修改 Win32 窗口样式。然而,Windows 上的应用就应该有 Windows 应用的样子嘛,在保证自定义的同时也能与其他窗口样式保持一致当然能最大程度保证 Windows 操作系统上的体验一致性。

本文将使用 WindowChrome 来自定义窗口样式,使其既保留原生窗口样式和交互习惯,又能够具备一定的自定义空间。


使用 Windows 原生窗口体验的应用

在自定义窗口样式的同时保证一致的 Windows 窗口风格体验的优秀应用有这些:

  • Windows 10 UWP 应用
    • 当然少不了 UWP 应用,毕竟这就是 Windows 10 窗口体验的代表
  • Google Chrome
    • 如果我不提第三方应用,你们肯定会说微软都是自己拿内部 API,拿黑科技做的
  • Windows 文件资源管理器
    • Windows 文件资源管理器也有一些自定义(例如在标题栏上放按钮,虽然实际做得很丑),不过整体来说还没 Chrome 做得精致呢

▲ Chrome 普通窗口

▲ Chrome 最大化窗口

为什么不做无边框窗口?

WPF 自定义窗口可是非常容易的,完全自定义样式、异形都不在话下。

<Window x:Class="Walterlv.Whitman.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:Walterlv.Whitman"
        mc:Ignorable="d" Title="Whitman" Width="800" Height="450"
        WindowStyle="None" AllowsTransparency="True">
</Window>

然而,这就不贴近原生窗口体验了,有这么多事情都不好模拟:

  • 最小化、最大化、关闭按钮
    • 按钮要多大?位置在哪里?图标边距又是多少,颜色值又是什么?鼠标滑入划出的动画效果如何?
  • 窗口标题栏交互
    • 标题栏上有右键菜单,如果自己模拟,基本上这个就要自己重新实现了。
  • 窗口的位置和尺寸
    • 你需要自己实现一套窗口的拖拽调整位置功能,需要自己实现一套拖拽调整大小的功能。而自己实现的方式在触摸屏下还很容易出现失效的情况。
  • 窗口的阴影
    • 要完全模拟 Windows 10 上的窗口阴影效果实在是一件头疼的事情,因为并不知道各种阴影参数是多少;就算模拟出来,性能也是个严重的问题。
  • 窗口的边框颜色
    • 虽然窗口边框是被广为吐槽的一点,但为了保证一致的窗口体验,这也是需要模拟的;正常情况和失焦的情况颜色还不一样。
  • 第三方应用集成
    • 第三方截图应用可以毫无障碍地捕捉到标准窗口的外框范围,但如果我们没有模拟好(而是拿一个 WPF 无边框窗口模拟),那么第三方截图应用就截不准(可能会超出窗口本来的大小)。

开始使用 WindowChrome

理论上 WindowChrome 的使用是非常简单的(呃……理论上)。你只需要在 <Window /> 节点里写如下代码便能够完成客户区(Client Area)到非客户区(Non-client Area)的覆盖:

<WindowChrome.WindowChrome>
    <WindowChrome />
</WindowChrome.WindowChrome>

然而,默认的行为却并不那么像原生 Windows 10 窗口。事实上,这样的写法只是简单地把窗口的客户区覆盖到非客户区,原生窗口中的交互还在,但样式都已经被遮挡了。

▲ 样式已经被遮挡

不止是样式被遮挡,我们应该能注意相比于原生还有这些不同:

  1. 我们的边框是白色的,原生的边框是系统主题色
  2. 鼠标划入我们窗口内才开始拖拽改变大小,但原生的在阴影区域就能开始调整大小了

现在,为了能够观察到 WindowChrome 各种属性设置的效果,我们为 Window 定义一个新的 Template,里面就是空的,这样就没有什么内容能够遮挡我们设置的样式了。

<Window.Template>
    <ControlTemplate TargetType="Window">
        <Border />
    </ControlTemplate>
</Window.Template>

▲ 没有遮挡的窗口

然而即便如此,我们也只解决了系统主题色边框的问题,没有解决调整窗口的拖拽热区问题。而且边框还如此之丑。

GlassFrameThickness

在官方文档 WindowChrome.GlassFrameCompleteThickness Property (System.Windows.Shell) 中有说,如果指定 GlassFrameThickness 值为 -1,那么可以做到整个窗口都遮挡,但实际上全遮挡的效果也是不对劲的,就像下面这样:

<WindowChrome.WindowChrome>
    <WindowChrome GlassFrameThickness="-1" />
</WindowChrome.WindowChrome>

▲ GlassFrameThickness 为 -1

不止边框颜色不见了,连右上角的三个按钮的位置都跟原生不同,这个窗口的位置不贴边。

显然,GlassFrameThickness 属性我们不能指定为 -1。

也不能指定为 0,你可以试试,会发现连阴影都不见了,这更不是我们想要的效果。

▲ GlassFrameThickness 为 0

那我们指定为其他正数呢?

▲ 指定为其他正数

显然,没有一个符合我们的要求。

NonClientFrameEdges

但好在我们还有一个属性可以尝试 —— NonClientFrameEdges。官方文档 WindowChrome.NonClientFrameEdges Property (System.Windows.Shell) 对此的解释是:

Gets or sets a value that indicates which edges of the window frame are not owned by the client.

即指定哪一边不属于客户区。

考虑到我们前面的尝试中发现左、下、右的边框都是不符合要求的,所以我们现在将值设置为 Left,Bottom,Right

<WindowChrome.WindowChrome>
    <WindowChrome NonClientFrameEdges="Left,Bottom,Right" />
</WindowChrome.WindowChrome>

▲ 比较接近的效果

这回我们终于看到了比较接近原生窗口的效果了,除了窗口的边框效果在激活和非激活状态下与原生窗口一致,连右上角三个按钮的位置也是贴近原生窗口的。甚至拖拽调整窗口大小时的光标热区也是类似的:

▲ 拖拽光标热区

唯一不符合要求的是标题栏高度,这时我们可以继续设置 GlassFrameThickness,把顶部设置得更高一些。

然而设置到多少呢?我测量了一下 Microsoft Store 应用的按钮高度,是 32。

但是,这 32 包括了顶部 1 像素的边框吗?我使用放大镜查看,发现是包含的。

而我们的 GlassFrameThickness 属性也是包含这个 1 像素边框的。所以含义一致,我们可以考虑直接将 32 设置到属性中:

<WindowChrome.WindowChrome>
    <WindowChrome GlassFrameThickness="0 32 0 0" NonClientFrameEdges="Left,Bottom,Right" />
</WindowChrome.WindowChrome>

然而实测结果是 —— 又被耍了,虽然标题栏有 32 的高度,但按钮只有 30 而已:

而且在最大化窗口之后,按钮高度继续压缩。标题栏只剩下 24 的高度,按钮只剩下 22 的高度了。

这显然也模拟得不像。于是,我们霸气一点,直接把顶部边距改得更大。为了凑个整,我写 64 好了。

<WindowChrome.WindowChrome>
    <WindowChrome GlassFrameThickness="0 64 0 0" NonClientFrameEdges="Left,Bottom,Right" />
</WindowChrome.WindowChrome>

虽然正常状态下的按钮依然是 30 高度,但最大化时还是 30 高度这一点与原生 UWP 窗口和 Chrome 的行为是类似的。(UWP 窗口按钮 32 高度,最大化 32 高度;Google Chrome 窗口按钮 30 高度,最大化 27 高度。)

所以,截至这里,我们算是模拟得比较像了。

其他的属性需要尝试吗?CornerRadius, ResizeBorderThickness, ResizeGripDirection, UseAeroCaptionButtons 在默认情况下的行为就已经够了;而 IsHitTestVisibleInChrome 是个与 WPF 相关的附加属性,与模拟窗口样式没有关系。所以基本模拟就靠前面的两个属性了。

定制 Window 的控件模板

WindowChrome 提供客户区内容覆盖到非客户区的能力,所以我们通过定制 WindowControlTemplate 能够在保证原生窗口体验的同时,尽可能定制我们的窗口样式。

在按照以上的方式设置了 WindowChrome 之后,我们能够定制的客户区已经有下图所示的这么多了:

▲ 可定制的客户区

特别注意:可定制区域中顶部是包含那 1 像素的边距的,但其他三边不包含。

下面的窗口是我在 冷算法:自动生成代码标识符(类名、方法名、变量名) 中所述算法的一个应用,除了右上角的一个白色块,在保证接近原生窗口的情况下,定制了一些内容。

▲ 一个试验品

为了保证标题栏的标题文字也尽可能地接近原生窗口,我也通过测量得出了用于显示标题的 <TextBlock /> 的各种参数。整理之后,写成了下面的样式:

<Window.Template>
    <ControlTemplate TargetType="Window">
        <Border Padding="0 30 0 0">
            <Grid x:Name="RootGrid" Background="{TemplateBinding Background}">
                <Border Background="{TemplateBinding Background}"
                        VerticalAlignment="Top" Height="30" Margin="0 -29 140 0">
                    <TextBlock Foreground="White" Margin="16 0" VerticalAlignment="Center"
                               FontSize="12" Text="{TemplateBinding Title}" />
                </Border>
                <ContentPresenter />
            </Grid>
        </Border>
        <ControlTemplate.Triggers>
            <Trigger Property="WindowState" Value="Maximized">
                <Setter TargetName="RootGrid" Property="Margin" Value="6" />
            </Trigger>
        </ControlTemplate.Triggers>
    </ControlTemplate>
</Window.Template>

需要注意,我写了一个触发器,当窗口最大化时根元素边距值设为 6。如果不设置,最大化时窗口边缘的像素将看不见。这是反复尝试的经验值,且在多种 DPI 下验证是依然有效的。实际上即便是最合适此时设置的 SystemParameters.WindowResizeBorderThickness 属性依然无法让窗口最大化时边缘距离保持为 0。

标题栏上的三大金刚

我们发现,在以上所有方法尝试完成后,还剩下右上角的三颗按钮的背景色无法定制。如果依然采用非客户区控件覆盖的方法,这三个按钮就会被遮挡,只能自己区模拟了,那是不小的工作量。

然而我们还发现,Google Chrome 是定制了这三个按钮的背景色的,正在研究它的做法。

不过 Win32 原生的方法顶多只支持修改标题栏按钮的背景色,而不支持让标题栏按钮全透明。也就是说,Win32 原生方法也许能达到 Google Chrome 的效果,但不可能达到 UWP 中的效果。

为了完全模拟 UWP,标题栏上的按钮只能自绘了。关于自绘标题栏按钮以模拟 UWP 原生按钮,可以阅读我的另一篇文章(代码太长,还是分开了好):WPF 应用完全模拟 UWP 的标题栏按钮

原生 Windows 窗口体验

UWP 应用对窗口样式的定制能力是非常小的,远远小于传统 Win32 应用。但因为其与系统原生集成,如果要求保证原生窗口体验,UWP 的定制能力又是各种方法里面最大的,而且 API 非常简单。

如果你正在使用 UWP 开发应用,可参考林德熙的博客 win10 uwp 标题栏 来定制标题栏。


参考资料

本文会经常更新,请阅读原文: https://walterlv.com/post/wpf-simulate-native-window-style-using-window-chrome.html ,以避免陈旧错误知识的误导,同时有更好的阅读体验。

本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。欢迎转载、使用、重新发布,但务必保留文章署名 吕毅 (包含链接: https://walterlv.com ),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请 与我联系 (walter.lv@qq.com)

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏前端知识分享

第132天:移动web端-rem布局(进阶)

      该方案使用相当简单,把下面这段已压缩过的 原生JS(仅1kb,源码已在文章底部更新,2017/5/3) 放到 HTML 的 head 标签中即可(注...

26130
来自专栏我分享我快乐

Adobe animate cc 界面解读

我们都知道Adobe animate cc 可帮助我们不用写代码的情况下完成简单的交互动效实现,但是对于初学者而言,英文界面成为想关注它的人望而却步。首先,我强...

471150
来自专栏腾讯大讲堂的专栏

打造H5动感影集的爱恨情仇【动画性能篇】

作者:谭照强,热爱折腾前端,喜欢新奇创意的程序员,业余喜欢玩摄影,弄咖啡。 “你听说过动感影集么?” 动感影集是QQ空间新功能,可以将静态的图片轻松转变为动态的...

325120
来自专栏企鹅号快讯

5个你可能不知道的CSS属性

每年都有新的CSS属性被标准化,并在主流浏览器中可用。 它们旨在使Web开发人员的工作变得轻松,创造出新颖美丽的网站。 在这篇文章中,我将介绍5个相对较新的CS...

20680
来自专栏互联网杂技

原生css写响应式网页

写在前面的话:随着移动设备的逐渐普及和Web技术的发展,跨端的Web开发需求将会越来越大。如何在多种设备上进行跨端的界面适配呢?我们可以利用CSS3的Media...

38090
来自专栏知晓程序

开发 | 小程序做动画效果难?送你一个框架,10 分钟就能搞定

在小程序中使用 canvas 绘制图案、动画的难度有目共睹。除了本身写法繁琐,小程序的技术特性,也使得小程序无法使用普通 HTML 5 的 canvas 框架,...

17350
来自专栏腾讯社交用户体验设计

极速适配 iPhone X 秘笈

21640
来自专栏Golang语言社区

【Go 语言社区】算法课程 第一季 第5节 回文检查

回文概念:大致就是把这个数倒过来念数字还是和原来的一样. 运行结果: 代码: package main import ( "fmt" ) //...

33840
来自专栏玩转全栈

小程序怎么将视觉搞实现成ui

这个真的是强烈建议,对于一个页面,首先应该大致的看一下可以划分为哪几个模块,通常的划分方式是,整体来看,是row排列,还是column排列的,那么,最擅长做这种...

352170
来自专栏互联网杂技

单选按钮的用户体验设计

单选按钮是表单系统的一个基本元素。它们被使用在当存在互斥的两个或多个选项列表而用户必须选择其中一个时。换句话说,点选某个尚未选中的单选按钮,之前的选择就会恢复成...

360100

扫码关注云+社区

领取腾讯云代金券