当前位置: 首页 > news >正文

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

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

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


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

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

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

Chrome 普通窗口
▲ 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

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

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

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

GlassFrameThickness 为 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。

Microsoft Store 标题栏

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

Microsoft Store 标题栏放大后

而我们的 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 是定制了这三个按钮的背景色的,正在研究它的做法。

原生 Windows 窗口体验

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

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


参考资料

  • DwmSetWindowAttribute function - Microsoft Docs
  • pinvoke.net: DwmSetWindowAttribute (Enums)

相关文章:

  • 理解 Roslyn 中的红绿树(Red-Green Trees)
  • (1/2) 为了理解 UWP 的启动流程,我从零开始创建了一个 UWP 程序
  • (2/2) 为了理解 UWP 的启动流程,我从零开始创建了一个 UWP 程序
  • .NET/C# 使窗口永不获得焦点
  • .NET/C# 使用 SpanT 为字符串处理提升性能
  • WPF 应用完全模拟 UWP 的标题栏按钮
  • 让控制台支持 ANSI 转义序列,输出下划线、修改颜色或其他控制
  • 在 GitHub 公开仓库中隐藏自己的私人邮箱地址
  • Win32 程序在启动时激活前一个启动程序的窗口
  • C#/.NET 读取或修改文件的创建时间和修改时间
  • 通过解读 WPF 触摸源码,分析 WPF 插拔设备触摸失效的问题(问题篇)
  • .NET 中各种混淆(Obfuscation)的含义、原理、实际效果和不同级别的差异(使用 SmartAssembly)
  • .NET 中 GetProcess 相关方法的性能
  • 常用输入法快速输入自定义格式的时间和日期(搜狗/QQ/手心/微软拼音)
  • 好的框架需要好的 API 设计 —— API 设计的六个原则
  • [ 一起学React系列 -- 8 ] React中的文件上传
  • [Vue CLI 3] 配置解析之 css.extract
  • [译] 怎样写一个基础的编译器
  • iOS仿今日头条、壁纸应用、筛选分类、三方微博、颜色填充等源码
  • LeetCode算法系列_0891_子序列宽度之和
  • Objective-C 中关联引用的概念
  • Vue2 SSR 的优化之旅
  • 笨办法学C 练习34:动态数组
  • 关于List、List?、ListObject的区别
  • 聊聊directory traversal attack
  • 容器服务kubernetes弹性伸缩高级用法
  • 如何实现 font-size 的响应式
  • 如何在 Tornado 中实现 Middleware
  • 设计模式(12)迭代器模式(讲解+应用)
  • 我是如何设计 Upload 上传组件的
  • 一个普通的 5 年iOS开发者的自我总结,以及5年开发经历和感想!
  • NLPIR智能语义技术让大数据挖掘更简单
  • ​​​​​​​GitLab 之 GitLab-Runner 安装,配置与问题汇总
  • ​【原创】基于SSM的酒店预约管理系统(酒店管理系统毕业设计)
  • ###C语言程序设计-----C语言学习(3)#
  • #多叉树深度遍历_结合深度学习的视频编码方法--帧内预测
  • (09)Hive——CTE 公共表达式
  • (Matlab)使用竞争神经网络实现数据聚类
  • (webRTC、RecordRTC):navigator.mediaDevices undefined
  • (带教程)商业版SEO关键词按天计费系统:关键词排名优化、代理服务、手机自适应及搭建教程
  • .NET Core Web APi类库如何内嵌运行?
  • .NET 设计模式—简单工厂(Simple Factory Pattern)
  • .NET面试题(二)
  • @AliasFor注解
  • @SpringBootApplication 包含的三个注解及其含义
  • [100天算法】-每个元音包含偶数次的最长子字符串(day 53)
  • [2669]2-2 Time类的定义
  • [Android]How to use FFmpeg to decode Android f...
  • [ARM]ldr 和 adr 伪指令的区别
  • [Hive] CTE 通用表达式 WITH关键字
  • [Java安全入门]三.CC1链
  • [Linux] LVS+Keepalived高可用集群部署
  • [Linux]进程信号(信号入门 | 信号产生的方式 | 信号捕捉初识)
  • [Luogu 2816]宋荣子搭积木
  • [Neural Network] {Université de Sherbrooke} L2.9 Param Initialization