WPF让人哭笑不得的BUG

　　前几天遇到了一个让我哭笑不得的bug，我写的Wpf程序在Win7里可以运行，到XP、WindowsServer里运行点击某个控件之后闪退，不报任何错，在后台代码里trycatch也捕捉不到任何异常。很明显，这不是后台的代码出的错。当时情况很艰苦，用户在十万八千里之外，他的电脑上也没有调试环境，我只能在本地一步一步排除错误可能，修改、打包、发布到用户、卸载、重装、足足折腾了一天，最后总算是搞定了。

　　不知道大牛们遇到这样的情况怎么处理。没有调试环境，本地运行良好，用户运行就闪退，没有任何错误抛出。大家先思考一番，你遇到这样的情况，你会如何处理。

　　我比较笨，第一步，把这个控件关联的后台代码注释，排除后台代码的出错可能。

　　第二步，既然不是后台代码的问题，那就是这个控件的问题了，这是个CheckBox，引用到一个写好的资源Style，由于不能到用户那里调试，本地也完好运行，那我就在窗体的Loaded里找这个资源，代码赋给这个控件。果然，本地报了一个“{DependencyProperty.UnsetValue}”不是属性“BorderBrush”的有效值的错误，心中窃喜，一看BorderBrush后面赋值的资源，在那个资源文件里找不到，放在了App.xaml里，那也行，那就把它弄过来，放到Style同文件里，本地运行，Ok，发布给用户，继续闪退。

　　第三步，现在十有八九是这个Style的问题了，是什么问题呢？每次我只要一点击这个CheckBox就闪退，那我就到Style里看看，点击时会有一个向右下平移的TranslateTransform执行了，难道是它？不管，删了再说，发布，继续闪退。再看，Checked为True和False的时候操作了一个Path，难道是这里有问题？继续删，继续闪退。

　　到这我就有点抓狂了，好吧，既然这个Style有问题，不用你可以吧，把引用Style的语句移掉，OK了。

　　虽然是正常运行了，但是问题的根本没有解决，由于使用默认的风格影响了用户的使用，必须使用自定义Style。那好吧，不用那个有问题的Style，用Win7的，直接复制副本到资源文件里，还是闪退。

　　我开始怀疑是不是系统有问题，用360修复了，问题依旧。

　　Google，百度，好像没有人有我这样的遭遇，我开始同情自己了。

　　蓦然回首，发现在不远处有台闲置的电脑，是部门的服务器，一般没人用，这让我看到了希望，远程到这台电脑，它是WindowsServer2003，上面也没有VS2010，但是毕竟是局域网，直接debug文件夹拷上去运行，一样闪退。

　　难道是混在资源文件里会出错？好吧，单独给你弄个资源文件，继续闪退。

　　没辙了，这个Style到底哪里出了问题，不能老这样闪退啊，好歹给我报个错，要哭了...已经没有什么我能做的了。

　　这时候我在想，是不是这个资源要用到App.xaml里的资源，运行时引用不到？好歹是个机会，于是把App里的资源全部移到Merged的资源里，发布用户，运行OK，原来正是如此！

　　总结：Wpf程序操作控件闪退，一般是由于资源引起的，如Style里的资源名找不到，写在分资源文件里需要引用到App.xaml里的资源等等，这时候要做的就是整合资源，App里面的资源全部整合到各自的资源文件里。如下：

　　<Application.Resources>

　　　　　　 <ResourceDictionary.MergedDictionaries>

　　　　　　 </ResourceDictionary.MergedDictionaries>

　　　　</ResourceDictionary>

　　</Application.Resources>　　

　　建议：在程序架构刚刚搭建的时候就注意资源的分流，不要全挤在App.xaml里，App.xaml只作Merged，不是必须不在App.xaml里写任何资源，新手可以那样做，老手千万不要贻笑大方啊。

[转]

巴特西

WPF让人哭笑不得的BUG

最新文章

热门文章