C# winform 开发

前言

没想到吧，说实话自己也没想到，居然回去接触这玩意。
Autohotkey 界面开发它不香吗，为啥还要搞个 winform 折腾自己。
不过用了 C# 的 .net 框架之后，感觉运行库上还是要比 AHK 完善很多，界面开发也可以用 VS 来拉组件。
AHK 虽然也有一些类似 Designer 的工具，显然没有 Layout 布局界面就很难受。

说实话接触这个一方面是自己有兴趣，另一方面刚好我之前的导师遗留了一个 winform 流程软件。
需要继续开发进行维护，于是我就主动承担了进一步开发的职责，好好熟悉了一遍 C# 的界面开发方案。
看完我导师写的 winform 的软件，感觉图形界面开发都是差不多。
大部分的逻辑处理其实都和 Qt 开发类似，可能这就是所谓的英雄所见略同吧。

C# 开发还有 WPF ，我还没有深入接触过，听说是基于 XAML 开发界面的。
听说那个是类似于 Vue 那种 MVVM 的设计模式了，有 DOM 结构的存在处理组件有一定的优势呀~
以后有机会也抽时间研究一下。

winform 开发

我当时也是在 B站上看了个简单的教程入门，用 4倍速过了一下基础，我大概看到 15、16 集左右就懂了。链接
其实 winform 也和 QtDesigner 差不多，可以通过工具箱拖拽 windows API 配置的组件。
然后搭建组件也是图形化编程，后面的业务逻辑再单独进行配置即可。

winform 没有信号槽的概念，双击组件会自动创建触发函数，直接写业务就可以了。
后面 winform 的基本上就是使用内部的库可以实现 windows 下的软件开发。
可以制作出一些流程工具。

我导师写的工具是检测资源目录的文件是否和引擎目录下的文件匹配
如果不匹配则通过列表提示出来，并且可以将美术制作用的资源目录自动合入。
不过现在美术有了新的需求，一方面是有些资源需要在引擎上查看修改结果，反而想要实现反向合入的操作。
另一方面，还想添加一些新的规则文件夹进行自动识别。

于是我就开始了，相关的研究。
其实修改需求并不难，我让美术给了一个测试的目录给我进行软件测试。
反向合入其实就加一个判断，然后让之前 copy 的路径翻转即可。
新的文件夹规则也可以查查源码可以找到一个 C# 的文件夹列表。
c# 的字符串也有类似 Python 的 r"" 不转义字符串，写法是 @""

在开发的过程中，我还发现了之前软件匹配文件是否相同的时候的 BUG。
文件是否相同居然用文件大小的 length 进行判断，这样很明显是不准的。
一些贴图经过了修改还是显示相等，因为像素的数量没有变化，只是颜色数据改变了，所以大小是一样的。
于是我又将这个匹配的方式改为 md5 的方式。
最后就是匹配方法有很大的问题，用了双 for 循环。
其实一个 for 循环就可以了，毕竟要转移的路径是可以推断出来的，不需要再获取一遍引擎路径下全部文件进行匹配。