迄今为止的设计都很顺利，但这次就不得不接触我前面所说的非常糟糕的流文档了，但在此之前先来把标题弄好：

 

 

 

 

 

效果：

 

 

接下来就是流文档嵌入工作了，还记得之这篇文章中编辑的流文档吗？我的计划是使用一个Frame元素嵌入这个流文档，Frame元素类似于网页中的iFrame，相当于内嵌的一个小浏览器，Frame可以进行导航，这样在需要时可以通过超链接来导航以显示各个频道的内容。

 

现在就插入一个Frame元素到标题下面：

 

 

 

 

 

Source指向了我们以前编辑的那个流文档，这看起来很好，但是如果你在IE中预览它的效果的话，你就会震惊了：

 

 

再往下看：

 

 

如果非要我用一个字来作出评价，还不允许带脏字的话，那就是“惨”。

 

我尝试过很多方法进行调整，比如列宽、列间距等等，均告无效，它始终都会以如此糟糕的形态出现。

 

分析其原因：

 

流文档的默认阅读器是FlowDocumentReader，这种阅读器过分复杂，并且我感觉很不完善。解决办法只能是在流文档文件中，为文档套上我们想要使用的阅读器FlowDocumentPageViewer，天哪，这令我作呕，我还怎么在多处重用流文档？

 

但这样问题还未解决，文档被嵌入后仍然不能横向充满容器。

 

这是因为我们的Frame没有固定的尺寸，被嵌入的流文档智商很低，无法跟随Frame进行伸缩，所以始终保持在一个窄小的横向空间中。解决方法还是用的一个龌龊的偏方，将Frame的宽度绑定到上层容器的实际宽度属性上：Width="{Binding ElementName=Content,Path=ActualWidth}"。

 

这方法有个后遗症，就是假如你浏览器宽度在阅览期间一直不变或者只是增大，那不会产生问题，但如果你尝试在阅读时缩小浏览器宽度，那么页面不会随之缩小。

 

WPF的液态布局中容器与内容间无法统一的缺陷真是太糟糕了，至少我一直都没找到优雅的方法。

 

除此之外，还有一点让人不可理解，就是在此页面定义的样式不会影响到内嵌的流文档，也就是说想定义样式就必须得在流文档里定义，这再次粉碎了我重用流文档的念头。

 

经过一番痛苦的蹂躏，先前的流文档被修改为这样：

 

 

 

请将这个保存为Info.xaml，然后将Fream元素也修改一下：

 

 

 

 

效果：

 

 

主页面全部代码：

 

 

 

源文件下载

 

总结

 

可以看到，一帆风顺的设计伴随着一个糟糕的结局结束了，流文档让我大失所望，液态布局存在巨大缺陷。

 

流文档如果不能很好的重用，那么它的意义非常渺小。

 

液态布局中容器和内容的尺寸冲突很可能是设计上的BUG，它们本应该通过公开的依赖属性来完美协调，但是它们根本没有那么做。

 

我希望这些只是因为我的用法不对而造成的结果，期待能有高手指出优雅的解决方式，如果无人能予以解决，那只能寄希望于微软完善了。

本文转自斯克迪亚博客园博客，原文链接：http://www.cnblogs.com/SkyD/archive/2008/08/30/1279913.html，如需转载请自行联系原作者