@斯克迪亚
不好意思过这么久才回复...不知道是不是已经解决了

覆盖所有UIElement的Focusable的默认值为False

首先PropertyMetadata在设置了之后就不能改变了，如果尝试改变就会发生上面的异常 反正不让随便改就行了
可以实现自己的控件，然后覆盖控件的元数据 像这样
public class MyTextBox : TextBox
{
static MyTextBox()
{
UIElement.FocusableProperty.OverrideMetadata(
typeof(MyTextBox),
new FrameworkPropertyMetadata(false)
);
}
}
不用担心覆盖了之后丢失父对象元数据的数据，OverrideMetadata方法是一个对元数据Merge的过程

如果是要改变默认样式，原理应该一样，继承之后覆盖元数据就行了

这种方法需要继承控件，有时候肯定不方便
另外一种方法就是像那篇文章使用Style，如果你愿意，可以直接给类型加一个Style

<Window.Resources>
<Style TargetType="{x:Type Button}">
<Setter Property="Focusable" Value="False"></Setter>
</Style>
</Window.Resources>

p.s. 很佩服楼上的美工技术...我一直搞不清怎么把Blend和vs结合起来做wpf...也在楼上的文章里学了不少东西

我这样来改变默认值：
Control.FocusableProperty.GetMetadata(typeof(Control)).DefaultValue = false;

但会引发异常，提示为：无法在属性元数据与属性关联以后对其进行更改。

即使在构造函数里执行此语句也是会得到这个提示。

这里有一篇文章里都提到了这个方法，甚至都提到了Focusable，就是没有给出范例：http://www.interact-sw.co.uk/iangblog/2007/02/14/wpfdefaulttemplate

希望你能指点我一下：）

很精深的一系列文章，意犹未尽，还希望能看到更多此方面的知识。
我对Metadata很感兴趣，我想覆盖所有UI的Focusable的默认值为False，以此来清理难看的焦点框，或者为他们统一换一个好看的焦点样式，该如何做？

非常感谢 好好学习了

多谢

@afhel
INotifyPropertyChanged是数据绑定里用的东西……跟DP没有直接关系
INotifyPropertyChanged和DependencyProperty关系是有点乱
好吧 那这两天有空我来说说吧 呵呵

看了很久，可是还是没有我要的东西。楼主说点DependencyProperty替代INotifyPropertyChanged的东西吗？

支持楼主普度众生。

有意思，学习了。

@阿拉伯顶峰
我不是很清楚，好像没有检查是否已注册属性的公共方法
不过如果你调用Register属性注册属性时如果有重复，系统会抛出异常

学习了

顶，怎么检查已经注册了这个属性啊！

期待下文...

顶完2007的DP，再顶2008的DP，楼主好文

楼主好文章，刚刚从MSDN上看了过来，昨天在MSDN上看了一遍，很模糊，今天再看了两遍，有点清晰了，再来楼主这趁热打铁更深入理解下:)
--------
引用“自己一个人学东西,怎么样才算会了?除了做东西,有两个检验的办法,第一是去给不懂的人讲,看看能不能把别人讲明白了,第二是写文章,看看理不理的清楚思路 呵呵”

这句话也很经典，呵呵

挺酷的啊

@天下叁
参考文章最后的说明2

编译通不过。提示：F:\Workspace\Lab\TwoToOnePokerGame\TwoToOnePokerGame\FormWinGame.xaml.cs(19,26): 错误 CS0263: “TwoToOnePokerGame.FormWinGame”的分部声明一定不能指定不同的基类

@Yannic Yang
当然是褒义，三个代表全文如下：
始终代表中国先进生产力的发展要求,
先进文化的前进方向，
最广大人民的根本利益。

尊敬的开发者你好，我是www.svnhost.cn站长小灰，诚挚的邀请你，加入svnhost大家庭，这里可以托管你的代码，以后随时修改。

有一个错误

牛人，顶了，下了去学习了

谢谢
代码看不懂，嘎嘎。
只是玩游戏。

谢谢

@YoHan
@生鱼片
谢谢支持 我会继续写
@John Rambo
...不知道什么意思 褒还是贬?

楼主是三个代表的典范。

支持

不错不错，期待下篇

@kains
可以理解，flex我不了解，sl和winform差别那不是一点两点的
关于你说的问题，sl一般是这么做的
布局时，容器将小球放在某个位置，比如“地上”
然后为小球设置rendertransform属性，添加一个translatetransform,通过变换y属性，可以控制小球竖直方向位置
添加一个animation,应用在translatetransform的y属性上，可以设置加速度为9。8，这样不写csharp代码就能完成模拟小球落下了
当然还可以实现更多的功能

wpf中布局过程和控制位置过程是分开的，也就是说小球会经过多次定位除了文章里提到的margin和布局之外，还可以使用上面的rendentransform和layouttransform两个属性，这些都是和容器无关的（layouttransform会影响布局而rendentransform不会）

在了解sl的时候更多的我是借助winform和flex来进行比较的。
从winform到flex对于布局我很好理解，但是从winform 和 flex来推sl我对这种行为非常困惑。


如果有个这样实现的“球”，这个球可以在任意一个容器中实现自由落体
那么这个 球 怎么控制他的容器中的坐标？球不可能知道他在什么容器里面

除了楼上强调的，主要是margin替代了多余的top，left这类东西

@海东青
因为后面想用专门的文章来说PropertyMetadata，所以这里只是带过
这里是double类型，所以没有初值也无所谓，另外用数据绑定调用的时候就算是引用类型也内建了判错的机制...

不过为了不误导人，我觉得也写上一些判错或者赋初值代码会比较好，现在就懒得该文章了，最后全部写完了我统一再处理吧

由父控件统一对子对象的布局进行管理
这话很经典

好详细

new PropertyMetadata(new PropertyChangedCallback(transparencyPropertyChangedCallback))

应当给transparencyProperty设置一个初值，如果是引用类型的话有时候操作会引起错误，作例子还是要讲明了好:)

路过，学习。

@编写人生
恩 谢谢指出 这里说的是不太清楚
关于XAML编译 XAML的层次就够会被编译成二进制的代码（就是BAML），另一部分会被转换成C#代码（就是**.g.cs），在运行时两者会被组合
我这儿想表达意思是XAML代码的动态编译有很多限制，无法像HTML那样可以随意的动态添加，组合。

HTML是动态的解释性的而XAML是需要被编译的

===============
这个提法是不正确的，至少目前是不对的。
WPF的设计人员在初期规划的时候的确是将WPF翻译成源代码，然后编译（就跟WinFrom一样），但是他们测试后发现，编译的代码非常的大（在包含大量动画和特效的情况下），而且，将WPF的XML使用二进制方式的一种特殊记录方式后，解释的速度和直接执行的速度只是慢了一点点，所以最终他们决定使用二进制压缩的方式解释执行。

一年前俺还没出道，路过

貌似WPF中的比较复杂啊

嘿，跨度弧够长！

WWF 应该叫 WF 了。

讲的不清楚，遗憾

你确定你需要支持多种数据库吗，不是的话就去掉那块功能
如果按照大牛们的想法，肯定能给你找出不少的orm或需要用的模式，但到底有没必要使用只有你最了解
所以建议把系统做出来，发现解决不了的问题再重构，先别考虑那么多了

@怪怪
@gakaki
谢谢评论和推荐……
我正在继续学习相关资料

实话说：
粗略的看了几个ORM（包含很著名的Nb**,Code**,....)
现在还是倾向于自己的数据访问方式+自己的代码生成器

堪为精品，顶

@gakaki
"如果对面向对象有兴趣的话 DDD真的是很重要的（ORM就是根据这种思想） 因为它会让你对系统的模型有一个清晰的了解 ，"

DDD仅仅是一种方法， 同时它关心的仅仅是面向对象编程中的一小块。 而且可笑的是， 现存的ORM和其它一些框架，恰恰在很多地方和DDD的理念相冲突。 比如在上次讨论中发现的， 使边界对象不恰当的侵入； 比如DDD的作者所说的纯洁性的问题。

一些面向对象大牛和DDD大牛之所以用得好这些东西， 恰恰是因为他们知道问题在哪儿， 而一些吹NB挣钱的家伙（这些人中有一些也有建设性的工作，另一些则是不折不扣的依附于潮流的血吸虫，还有一些两者兼有）， 正在把追随者们引入误区。

推荐爱你INFOQ上的http://www.infoq.com/cn/interviews/jimmy-nilsson-linq-cn
还差一本书 《领域驱动设计 软件核心复杂对应之道》
推荐javaeye论坛 关于领域模型的讨论 rubyruby
推荐 POJO IN ACTION
.NET现在有2本了
http://domaindrivendesign.org/

除了三本书之外
还有UMLCHINA的访谈和.NET ROCKS对DDD一书作者的演讲
http://www.umlchina.com/Chat/TimMcCarthy.htm
http://www.umlchina.com/Chat/jimmy.htm


一点不夸张的说 如果走面向对象的方向 而不是面向数据库编程的话
如果对面向对象有兴趣的话 DDD真的是很重要的（ORM就是根据这种思想） 因为它会让你对系统的模型有一个清晰的了解 ，而且这种概念上的模型将是无关于程序语言的，也就是说可以重用在如何的面向对象语言上。

@Yannic Yang
嗯， 我这捣乱分子也不是白当的 :P

"使用EDM，使用ORM工具进行开发的前提下"

这不是给自己下套么..， 除非你有一个技术领导， 非让你如此不可。 我觉得这方面可能JavaEye上的家伙们确实更有经验一些。 不过我之所以这么言辞激烈， 就是想提醒一下， 之所以这么多年来讨论来讨论去， 解决的只是各种各样的细节， 而没有实质性的进步， 很可能是这种方案解决问题的能力只能到此为止了， 所以我们要更多的去关心它添加的麻烦。

掌握面向对象， 要站在面向对象之外； 掌握这样那样的构架， 最终也是要看你了解它多少弊端而不是优点。

关于证据的问题， 我倒是觉得面向对象的适用性的证据， 已经足够多了， 而且大家也*看见了*。 面向对象的不适用性的证据， 也已经足够多了， 可惜因为一些商业公司带来的舆论导向和在这种导向下的开发者社区存在的政治问题， 大家就*看不见*。 不害臊的说，对面向对象的思索和了解， 我也算有两把刷子了， 可我反而向它叫板， 难道是我脑子有病吗？

说实话， 大家想想咱们除了工作要求之外， 为什么会采用自己熟悉的平台，难道仅仅是因为我们对它的接口有更多的记忆？ 还不是因为我们的“熟悉”也包括熟悉它的缺陷， 知道如何绕开或者补救？ 说实在的， 这就是我评价一个人是不是懂得一个东西的关键： 咱们知不知道它哪儿不好， 对这些不好理解的有多深刻。

一个东西的好处， 往往你还没深入了解， 就感到了， 甚至没感到， 也受益了； 可它的害处， 尤其是不能解决的根本性的不好之处， 你没抓住它之前， 它就会带来潜在的祸害， 而且往往很难很敏感的及时意识到。

所以我才说， 现在不光光是研究和宣传这些玩意多好、怎么更好的时候， 而是应该开始考虑和曝光它们如何不好、而且是不是不解决一些根本性缺陷就已经没法更好的时候了。