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

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

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

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

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

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

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

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

LZ花一整天安装一个系统就感觉不错了？要我就得疯了……

刚好我昨天装的Ubuntu 9.04，装了两次才成功，之后安装了个显卡驱动就给我来个黑屏；之后用BT下个东西，给我死机……寒，晚上又重装了XP。

补充一下问题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）

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

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

哥们很勤奋啊，4月1日发了14个帖子。
支持博客园的心情是可以理解的。不过帖子还是要质量的，不是看数量的。而且如果是转载或翻译的文章，也是要注明出处的。

看原文上:

"Live Toolbar is a technology used by many millions of users across the world.  "

然后原作者就得出结论说:

This feature is rolling out across the world and is currently only available in US and Taiwan, however, it still shows a potential of being able to being able to handle a huge scale of millions of synchronization users through the use of Microsoft Sync Framework.

个人感觉是没有多大说服力的。
 
1. “many millions ” 里many到底是多少？
2. 这个功能只在美国和台湾开发，占全球多大比例？
3. 同时使用这个功能的人最多能有多少？
4. 每个人的收藏夹平均有多少数据量？
5. 微软用的服务器（机群）是什么配置？

这些都了解完了之后，再和自己要做的功能的需求和硬件条件做比较，才有可能知道MSF能不能符合需要。

王婆卖瓜，自卖自夸。微软很有理由在自己的BLOG上表扬自己的产品。^_^

不知道LZ有没有了解过这个功能的峰值并发用户数有多大呢？

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

@Zealic
多谢LZ，不过我的问题是，安装的是VS2008，可以编译2008，但是编译不了2005的sln。把sln文件里2005改成2008就可以了吗？

看完LZ的文章受益匪浅啊。不过有一个小问题。

项目中用MSBuild刚好遇到了一个问题，有的项目是VS2005,有的项目是VS2008的，而CI Server上如果只安装VS2008，在使用MSBuild编译VS2005的sln的时候，会编译不过，MSBuild要求把VS2005的sln升级到VS2008的sln……当然这是不可能随便升级的。不知有什么办法让MSBuild向下兼容吗？

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

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

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

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

@Muse

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

@hxmhj
我感觉LZ说得与你说的并不冲突。LZ应该是在说量的问题，不要把过多的逻辑放在数据库。

数据库就是放数据的，数据库不应该成为逻辑的核心，当然客户端也不是。只能说核心应该在服务器端，数据库只是核心的一部分。

LZ解释得很清楚，自己去Reflector的时间都省了。

老赵的建议倒并不觉得“很好”。

这个问题我也遇到过很多次了，多数情况下要求就是这个委托要异步调用的。…………

想知道.NET的GC是如何判断一个对象还有没有Alive Reference的。

好长~~有个图就好了。:)

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

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

汗~~一看挺长，再一看挺短，仔细一看，LZ是xjmqq？

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

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

真是用心良苦啊。

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

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

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

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

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

你真的有三年WPF经验吗？

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

为ListBox添加一个SortDescription，按DeskPosition排序即可。现有代码不用改，添三行XAML就可以了。

@YJJ
@aierong
楼主给一个关键字让我们自己搜索的。

@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，而是我代码的问题，那么请给出正确的代码。而不要在这里空谈。

谢谢。

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

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

很好啊，运行效率怎么样？比如内存占用。是用什么开发的呢？WPF？WinForm？MFC？Win32？

PS：那个滚动条不太和谐啊。应该不是WPF，如果是WinForm的可以EnableVisualStyle。

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

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

@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，也不是没有依据的。

总有人不看正文就大放厥词，术业有专攻而已。

支持LZ一下。

@ocean
谢谢你的科普啊。不过您说的我都是知道的。

不过麻烦您那怕先用脚趾头想想，如果WindowStyle = WindowStyle.ToolWindow可以达到目的，我还写这个BLOG干什么？

Window按形态你知道的有哪些？ToolWindow是什么？在什么时候用？您自己搞明白了吗？

@ocean
我真的是无语了，您有认真看过我的BLOG吗？你说的要用Hide，没有错。但是我从来没有说过Close之后再调用ShowDialog会有异常是个bug啊。

而且我的原文里，我自己也已经说明了啊。

@ocean
谢谢，你又搞错了，我没有说Visibility的存在是个bug。我不太确定您看明白了标题。

@ocean
谢谢你详细的解说哦。
你说的很对。但是很遗憾，你和我说的不是一回事儿……

我没有说变成线不对。而且那个height是我特意加的。只是为了让大家更清楚地看到那个红框。不然就变成线了，不容易看到。

我的要求更过分些。当adorned element不可见时，adorner layer上的东西也应该消失。这才我要说的。谢谢。

@Colin Han
呵呵，谢谢。对你的不以为然表示尊重。写这个文章本来就是给大家提个醒，让大家知道用Window的时候有这么个地方要注意一下。如果觉得不是个问题，当然更没有问题了。至于MSDN，的确实在是“不求甚解”啊。

@韦恩卑鄙
多谢你的支持。真理不辩不明，在讨论中共同进步。:)

@ocean
谢谢你的回复和提醒。如你所说，的确是应该用Hide()隐藏窗体，但是如果所有的事情都可以用Show，Close，Hide完成了。还要Visibility干什么呢？仅仅是因为从UIElement继承来了一个没有用的属性吗？其它所有控件都是用Visibility来隐藏，就是Window例外，实在是看不出原由啊。

@billrobin
有啊。要仔细看啊。

用Dictionary<string, delegate>可以吗?

@痴情客

原来只有像你一样搞Flex，搞Script才“有用”，才不算瞎搞。学习了。

其实偶要雷锋上的东西基本都能在别的地方找到。何必呢？

@Amo.Xoo
:(不知道啊。

YY：
bool IsHarmful(string url)
{
return ture;
}

23：19问题已经修复。