PS:
其实只要 * sizeof(TCHAR)就可以了。

这不能算个bug，要不然父窗口就一直保持disabled状态了

@木头象
多谢。
又学了一招，加参数。^^

@Franz
我承认我语言表达能力有问题，但是我好像没有表达出“奇怪”的意思吧。

我只是发现返回List<T>与返回IEnumerable<T>在应用上的不同（不讨论生成的IL有什么不同），给不知道的人“提个醒”。

如果有人问“缓加载有什么不好？”，我想我的文章更是在回答这个问题。

@风中灵药
谢谢你的理解。

不过很不幸，我记得自己好像是理解了IEnumerable的原理才来这里大放厥词的。所以标题叫“提个醒”，而不是“疑问”之类。

如果我没有理解错误，IEnumerable和foreach一起用才会被展开成对于Enumerator的MoveNext之类的函数的调用。没有foreach，就不会有Move，就不会遍历列表元素，就会有我文章中描述的问题。

楼主是一片好心，但楼主确实没明白IEnumerable的原理。

for /r %1 %%f in (.) Do If %%~nf == %2 rd /s /q "%%f"

改进一下：
1，增加参数1 源代码所在顶级目录，参数2 要删除的目录名
2, rd /q 安静模式

献丑了。

缓加载么,没有什么好奇怪啊!

傻B楼主自以为是

补充一下问题4的答案

Inside Microsoft.NET IL Assembler一书中写到。

“The common language runtime object model supports only single type inheritance”

我原以为IL会强大一些，支持多继承。看来IL也是不支持多继承的。

那么.NET 中 struct 不支持继承就可以理解了。因为所有struct都已经隐式继承于ValueType类了。所以就不能再继承别的struct了。（在IL中，struct就是一个class）

@南柯之石
const使用场合就是在程序运行前就已经知道值的，一般不会改变的；
static readonly是在程序运行前不知道的，需要在运行时赋值的常量，如web.config里appsetting里面的一些值就可用 static readonly.
另 其他问题的解释还请楼主分享

@iIMax
呵呵，没有错。但是主要什么时候用呢？

@good man
有啊，叫《框架设计（第2版）》，很经典的，推荐收藏。因为有纸版的，我还真没有电子版的。

5:const 编译时常量； static readonly 运行时常量

现在有中文版本的不啊
我也想买一本来看看啊，你那里有电子书不

是啊，現在所謂的名勝古跡、江南八大古鎮已經沒多少可觀賞性了。
放假還是回自己的家鄉，去鄉下走走也比畫這些冤枉錢強。

@czq662
小小程序,实不敢当.敢问是何问题?

求教！

@BurningRain
多谢BurningRain的支持！^_^
我也会继续下去的。

这篇文章好像ocean没有看到，感觉冷清好多啊。其实我在第一篇里就已经说了，有些可能不是Bug，只是用起来感觉很不爽的地方。

更感谢你后面提供的Grid的ClipToBounds的宝贵资源，之前还真没有注意到。看过MSDN上的解释，控件的边界计算、大小计算之类是个比较复杂的过程，一直犯懒，项目中也没有需要用Custom Panel的地方，也就没有深入了解过-_-。不过个人比较倾向于把它归为一个毛病……。

另外我的小组在开发过程中遇到的一个“现象”（先不用bug这个词了-_-）感觉也可以归入这一系列哦，博主要觉得有用的话可以考虑下放进来：
起因是程序中的一个应用场景，大概是这样：一个固定大小的Grid里放着一个Image，Image的初始高宽比Grid的高宽要大的，然后需要在某个时候把它缩小至能在Grid中全部看见，结果发现Grid总是会将超出其边界的部分直接clip掉，这样缩小了以后还是缺胳膊少腿的。即使ClipToBounds设成False也一样，比如：
<Grid Width="100" Height="100" Background="Green" ClipToBounds="False">
<Ellipse Fill="Blue" Width="300" Height="200" />
</Grid>

内部的Ellipse超出Grid高宽的部分总是会被clip掉。但是按MSDN上的说法“当 ClipToBounds 为 false 时，父元素的 Height/Width 设置不会剪裁内容”，是偶理解有问题，还是...
这个到是把容器换成Canvas就没事了，不过对这个问题的解决又引出了一个有意思的现象，如果把先把放一个Canvas放在这个Grid里，再在Canvas里放个大过Grid的元素，也是没问题的：
<Grid Width="100" Height="100" Background="Green" ClipToBounds="False">
<Canvas>
<Ellipse Fill="Blue" Width="300" Height="200" />
</Canvas>
</Grid>
上面这个写法也表现正常（Ellipse未被clip）。原因貌似是Canvas总是会对其父控件将自身大小返回为(0, 0)，自然Grid也就认为没有东西需要Clip。
不知道这个不分三七二十一的clip是不是Grid的一个毛病，也不知道Canvas对父控件返回(0, 0)做为大小算是“特性”还是也是个毛病...

这个系列挺不错的，一定要继续哈。
在之前几篇中看到ocean和博主为“bug”这一概念辩论得挺激烈，其实没那么严重啊。确实如何定义bug是跟需求的具体场景有关系的，有些“现象”放到特定的应用也许是不能算成bug。不过争论这个就偏离了博主的本意了啊。就算这些都不是bug，也不能否认它们确实是很不错的实践经验吧，知道了怎么也不是坏事，以后就能多个心眼，避免在做项目的时候钻到死胡同里浪费不必要的时间。也许有人会把不该算bug的理解成了bug，然后骂微软。但微软被骂的还少么，Windows那么多人在用，还不是有许多人一边用一边骂，一边骂一边还是很爽的在用（我一同事就是）...
也许是因为我也正在项目中使用WPF的关系，比较能理解博主的用心。再说ocean的一些补充也很不错的，让整个观点更系统化了。这样的交流是好事嘛，之后的对于bug与否的争论就不必要了。

好像Linq就是用yield做出来的

怎么会有人这样用呢，这东西设计出来就不是这样用的。
好比穿着高跟鞋在跑道上跑步一样奇怪。

@eeeeeeeeeeeeeeeeeeeeeeeeee
仁者见仁，智者见智；在我来看，绝对的算。

晕,这算缺点么?

@Muse

好在Word里的光标不会跑界外去。^_^

曾经被这个问题困扰了几天时间，微软的bug就是累人啊，这么明显都没测出来

是有这个问题.
空格不会回行与Word的排版规则是一样的。
但是我也觉得，对于输入控件，空格是一个字符，即使排到行首，也不能当成“空白”来处理

动物园里，大小对小孩说：你看猴多傻，我给他点吃的，它就翻跟头；老猴对小猴说：你看人多傻，我随便翻个跟头，他们就给我吃的

上海，上海人对上海人说：你看外地人多土多寒酸，连肉都没吃过，都吃些便宜的素菜；外地人对外地人说：上海人多可怜，咱们老家拿来喂xx的野菜，上海人抢着吃，还说是健康菜，想吃个正宗的土鸡蛋，还得费不少劲，咱们老家，随便哪家鸡下的蛋，都是土鸡蛋

呵呵，立场不足，观点不同

呵呵,我正好与博主相反.我是南方人,在北京工作.老家是与上海隔江相望的南通.我挺喜欢北方的饺子,比我们那儿的做的好吃多了(南方普遍的不吃饺子).北方人很热情豪爽(这点比南方人强太多),很容易交朋友. 南方人也不都像上海人那样,上海人天生的看不起任何地方的人,只要你说的不是上海话,都管你叫乡下人.

great

如果有条件，还是建议使用VS自带的，毕竟集成度高，代码覆盖很直观，且精度高。

用NUnit + NCover + TestDriven.NET，成本低，通用性好。哪天公司说要降低开发成本了，改用SharpDevelop开发了也方便。（全都免费了才好呢~~）

无语~~

你看，一般有多种口味的食品都会这么写

“奶油味”
“巧克力味”
“草莓味”

真是用心良苦啊。

@ocean
一直没有回复你，因为感觉我们都需要先冷静冷静。
首先，感谢你丰富详实的回复。

但是，你在回复之前为什么不自己做做呢？
你说“如第8篇里面，实际上你的灰线只要往下拉6个像素，避免在设计时就打破MaxHeight限制就不会存在。”

事实上满足了你的条件，问题也还是存在的。

你说“z-order或者说z-index并不是仅在一个panel内有效的，WPF的所有元素及子元素都可以排出一个z轴顺序。”

希望你能自己先写个代码验证一下再说吧。如果你认为应该是这样的，那么谢谢你，WPF又多了一个BUG，因为WPF的确不是这样的。

你真的有三年WPF经验吗？

Bill Gates自己都说过，永远不要向复杂低头。布局是很复杂，关联性强，但是MS应该有实力做出正确的结果吧。

你妈了个臭逼，少数没头脑逻辑的台山一带的蠢驴@反对吃猫

回14楼，这个问题你有点较真了，在你第5篇blog里面，你所认为的bug问题描述：

---------------
问题描述：用ShowDialog方法弹出一个模态对话框，然后将此对话框的Visibility属性设置为Hidden，再设置回Visible，发现这个对话框已经不是模态的了。
-------------------------

也就是你认为Visible变一下，就不是模态了，所以称为一个bug。

而你的应用场景也在第5篇里面写了：

----------------------------
应用环境：有些对话框，从逻辑上就是单例的，比如Office和Visual Studio里都有的查找对话框，显然没有必要同时显示两个。而且也没有必要每次重新实例化并显示出来，在用户关闭窗体时，将窗体隐藏起来会更好，这样上次查找的关键字还存在着。可以省去一些代码保存这个历史关键字。
-----------------------------------

而这个应用环境的本意无非就是希望初始化一个window，然后能不断的调用ShowDialog。而你写第5篇的文章，根本原因就是在于你没有注意到Hide方法，反而和Visibility及Close方法纠缠不清。而实际上Hide()这个方法已经可以很好的满足你的场景了。

而你这篇文章，前半部分谈了很多第5篇文章的内容，所以我的 有些回复也是针对第5篇的。

我将近3年前就开始做WPF，从Avalon就开始，接触过很多WPF的问题，所以这也是为什么我比较仔细验证你的文章的原因，因为我想看看是否能提出比较严重的bug，以便更好的能够提交更改，而实际上你很多篇关于bug的文章都是在界面上纠缠不清，有些地方你只要略加改动一点，这些问题就不会出现。
如第8篇里面，实际上你的灰线只要往下拉6个像素，避免在设计时就打破MaxHeight限制就不会存在。
而第7篇里面，z-order或者说z-index并不是仅在一个panel内有效的，WPF的所有元素及子元素都可以排出一个z轴顺序。
对于第一篇里面，问题主要是在界面描绘上，虽然仍然是单选，但是界面上看起来像多选，这种情况换一个写法就可以，这种问题提交到微软也未必会受理。当然这确实算是一个界面上的小问题。
至于第2篇文章，radiobutton绑定失效这个确实是一个bug。而且没有任何解决方案来代替，当然除非你不用radiobutton，不过换了控件那就不叫解决方案了。
至于第3篇文章，这个问题我正在研究，因为我按照你的示例代码下载运行后你所描述的问题没有重现，但是我看回复中好像很多人重现了这个问题，所以我准备过几天换个系统测试一下。:)

布局的这种问题，有时是没有办法说清楚的，如果按照你的这种标准来算的话，那WPF的bug就多的数不过来了。而且MS就算知道也未必会改，因为更改一个小地方，可能会引起其它布局上的bug，毕竟关联性太强，而且有些是相互矛盾的，所以一些在很特殊情况下才会碰到的布局问题，就很难作为bug来处理了。

@ocean
恕我直言，您给我的感觉，就是一个自我感觉良好的DEV，被QA报了一个BUG，就很不爽地和QA这那那这地找理由。

WPF的Bug比你想象得多得多。

BUG的概念比你想象得广得多。

别把自己的眼界和思路局限住。

想想，如果FLEX有同类的技术，却没有同样的问题，你又有何感想呢？

找BUG，别从实现看；找为什么会有这个BUG，才需要看实现。

@ocean
1. 你自己的例子就说明了，需求才是决定程序和文档的根本。不符合一个合理的需求（且不与其它更合理的需求冲突）就是BUG。

2. 不是MS故意取消了z-order，而且根本做不到。z-order只对同一个Panel内的控件起作用，而Adorner Layer是独立于控件所在Panel的。

3. 我描述的Bug与z-order没有关系。

4. 如果你只是用WPF，看MSDN做过几个小DEMO，还是多花两年研究研究再来阐述这个问题的根源吧。

@ocean
从需求的角度来看，这就是一个Bug，MaxHeight属性没有起到它应该起到的作用。

我所看到的就是这样。你也不必用什么借口来搪塞。即使运行过程真如你所说，也是有问题的。

你维护MS产品的心情我能理解，但是请你不要因此对客观存在的问题视而不见。

你的例子也根本说明不了问题。

那设置Height=*,MaxHeight的行为又是正确的你做何解释？

行为不正确，不要用代码实现如此当借口，没有人听的。

用的人只需要真心他想要的效果是什么，没有达到效果就是BUG。

如果你想证明这不是一个Bug，而是我代码的问题，那么请给出正确的代码。而不要在这里空谈。

谢谢。

没有完成它应该完成的工作，就是bug，这么说也可以，但是什么是应该完成的工作，显然不是某个人说了算的，文档中描述的工作才是它应该完成的工作，所以换言之，和文档一致的行为肯定不能算是bug了。

因为你可以换个角度想想，有些人希望当有error时，无论什么情况下都能看到，而如果根据你的这种需求来改，那么当被覆盖的时候这个error就看不到了，这样可能就又不会满足另外一些人的需求，那么另外一些人是否也可以写一篇文章，说error被覆盖时就看不到了是一个bug呢？如果那样的话，无论怎么改都是有bug，这显然是不合乎道理的。所以这种设计更多是体现了另外一类人或者另外一些场景的需求，也就是希望error总是能看到，故而取消了z-order的限制。

其实任何设计都是有其相应的道理的，任何一个设计也不可能覆盖所有的场景，任何一个设计可能我们都能找到疏漏的场景，那么是否可以推论任何设计都有bug？

回4楼，你还是没有搞清楚，这个是在初始化是产生的，随即maxHeight就恢复正常，而不是一开始就失效。

初始化时导致actualHeight > maxHeight，因为你的那个是row的maxheight，而表格中的行是相互关联的，也就是你这3行是是在一个Grid里面的，那么就必然会一行变小时另外一行就会变大，程序的布局是动态的，而不是静止的，所以本身你就不应该用静态的这种眼光去看问题。这就是有时我们设置一个属性，但是发现这个属性不起作用，原因就在于整个程序是动态的，特别是布局的属性，你想如果你同时设置了margin, left, width之类的，那么必然就会有一个失效，因为属性之间会相互影响。

我举个例子，比如你让一个表格是100%，里面有两列，一列你设置10%，另外一列你也设置10%，那么你发现肯定有一列的宽度有问题，因为既然只有两列，那么两列加起来肯定是100%，否则显示上就有问题了。

如果你总是用这种静止的观点去分析程序，那么你会发现非常多有问题的地方，但是如果你用动态的观点去分析，就会发现很多东西就没有问题了。

另外你还是没有搞清楚什么叫做一个bug，1：和文档一致的行为，不能叫做bug。2：即使某个行为文档中没有描述，也未必是一个bug。

所以这种情况你就干脆不用废时间去微软提交bug了，可以很负责任的告诉你，不会被受理的。

@ocean
“凡是和文档一致的行为都不能称之为bug。 ”

看来修BUG有两个途径了——改代码，或改文档。

@Terry Sun
还没有，微软的Connect网站实在太慢了。一直打不开（我电信），请问有别的途径吗？

@ocean
原来程序一运行MaxHeight就失效啦？你不说我还真没发现。这个BUG看来更严重哦。

提交到MS了没有

不过这也算是个小问题，就是在于最后一行那个Height是Auto的原因，导致程序初始化时ActualHeight就成了55.96，超过maxHeight了，归根还是因为那几行是联动的问题。

老大，真被你打败了，你自己好好想想这是怎么回事。MaxHeight不起作用的原因是因为你设计时的那个row的实际高度为55.96，也就是说当程序启动起来的时候，根据你的设计界面，那个Tab所在的行已经是55.96了，你可以把那个row的height, MaxHeight和ActualHeight都拿出来看看，分别是1，50，55.96。所以当你第一次显示那个tab的时候，因为原本就突破了maxHeight，所以就直接按照那个tab的最终大小来显示了。

而当你拉那个GridSplitter，为什么会突然变小呢，那是因为拉动GridSplitter的时候，会重新计算行高，这是MaxHeight就直接起作用了，拉动GridSplitter后，你再观察height, maxheight和actualheight，你就会发现都是50了。

所以修正你的这个问题很简单，你只要在设计时的界面，把最后一行往下拉6个像素，不要让设计时的行高超过maxHeight，这样你的问题就不会出现了。


所以这个也不能算是bug啊，分明是你程序的问题。


你的文章上有一句“可能大家不知道50px有多大，大概就是现在灰线下的部分的高度。”，实际上就是这个有问题，这个灰线下的高度是55多一点，已经超过了MaxHeight了，你只要把这个灰线往下拉一点，让灰线往下的部分真正小于50，这个问题就不存在了。

@ocean
对您的严谨表示由衷的钦佩。言辞如有冲撞之处还请见凉。

将其归入WPF bug，也有历史原因，你如果看过之（1）之（2），就会发现那的确是Bug，既然是一个系列，我自己自然也想多写一些，把自己知道的WPF用得不爽的地方都告诉大家，好让大家用之前有个心理准备。

wikipedia上对bug的定义：A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended。

其实只要是没有完成它应该完成的工作，就是BUG。

这个红框的BUG，就是我所做的一个项目中存在的。我们的QA报了BUG，但是这又的确不是我们Dev的问题。只能说是WPF的Bug，并希望MS在.NET 4.0中能解决这个问题。

你的建议非常合情理，但是说这是个BUG，也不是没有依据的。