Volunteer .NET Evangelist

Client端的异步调用并不需要指明AsyncPattern.而Server端的异步调用则需要指明AsyncPattern为true.
这点在我这篇blog里面有说明:
http://shevaspace.spaces.live.com/blog/cns!FD9A0F1F8DD06954!588.entry

Sheva

Edit:刚才试了一下客户端的异步调用也需要AsyncPattern=true:)

to Cat Chen
很多人一开始特别喜欢拿HTML/CSS和XAML进行比较，XAML的Style语法从很多角度上看要比CSS的更合理，更简捷。
起初的时候微软就象把CSS的语法引入到XAML里面去来定义样式，但是最后他们发现这样一来他们就给XAML进入了一种新的语法，一种和XML不兼容的语法，这样就给他们编写XAML分析器带来了很多的困难，而且从开发人员的角度上看，一种编程进行进入太多的语法不是一件好事，这种弄会给开发人员带来更大的负担。
但是这些都还好，最终微软放弃CSS语法是因为XAML的样式所要支持的东西比CSS更广泛，XAML的Triggers用CSS就不可能实现。所以最终微软开始决定此阿用一种兼容XML的样式申明格式。所以XAML其实就是XML，它没有引入什么新的标识语法。这其实是一件好事。
但是WPF的样式也要问题的时候，我今天就发现了一个Bug,我的这篇post里面有详尽的说明：
http://shevaspace.spaces.live.com/blog/cns!FD9A0F1F8DD06954!548.entry

Sheva

@kw2007
Win32 APIs are built on top of Windows System kernel APIs, those APIs are consistent across different versions of Windows. But there are some APIs which are specific to a particular version of Windows, such as DWM related APIs are only available on Windows Vista, but the common denominator of those APIs are all callable on different versions of Windows.

Sheva

Windows Vista SDK里面有例子展示怎么在托管代码里面使用Vista的这些新功能：
Your Installation Driver:\Program Files\Microsoft SDKs\Windows\v6.0\Samples\CrossTechnologySamples\VistaBridge

Sheva

学习.NET的时候就发现Marshalling和Serialization这两个词不好翻译，因为在有些场合下这两个词是一个意思，比如.NET Remoting, DCOM, RPC. 而在 COM STA线程模型里面，这两个词又代表不同的意思。所以这两个词最好不要翻译。

Sheva

WPF不只是给Graphic Designer提供了发挥的平台，对我们这些Coder来说，WPF也有具有革命性突破的地方。比如WPF新的图形输出模式。WPF的自定义控件开发，WPF的数据绑定，WPF的样式和控件模版等等都是非常令人兴奋的。

Sheva

"但是由于Windows XP中没有虚拟化显示卡资源，只能强制所有的应用程序都采用软件提交"
I don't know where you get this message from, but in actuality, WPF are both hardware accelerated on Windows XP and Windows Vista. There are just some optimizations enabled by DWM and WDDM which are only available on Windows Vista. Tim Sneath has a great blog article explaining the difference of WPF on Windows Vista and Windows XP:

Comparing WPF on Windows Vista v. Windows XP
http://blogs.msdn.com/tims/archive/2007/01/05/comparing-wpf-on-windows-vista-v-windows-xp.aspx

Sheva

原来如此呀，毕竟这本书刚刚出来，国内应该没有的:)

Sheva

其实关于资源，介绍一下WPF里面资源的解析过程比较好，这是WPF比较有特点的地方。

Sheva

楼主有这本书呀，能否共享一下。
我的邮箱地址：footballism at gmail dot com

Sheva

好文章，不知道楼主的那个DP值计算过程的图片是哪里弄来的，能否告知？

Sheva

关于继承上下文(Inheritance Context),Nick Krammer的blog讲得非常详尽：
http://blogs.msdn.com/nickkramer/archive/2006/08/18/705116.aspx

Sheva

实际上WPF的事件处理是基于视觉树(Visual Tree)的，而非逻辑树(Logical Tree)，而属性继承(Property Inheritance)以及资源查找(Resource Lookup)则是基于逻辑树的。

Sheva

如果有问题，可以到MSDN WPF论坛去问，而且最好要附上repro代码：
http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=119&SiteID=1

Sheva

WPF依然是基于信息循环(Message Loop)的应用程序框架，而且WPF的所有鼠标和键盘的操作都需要通过与USER32互交才能获得。

PS:我以前写过关于WPF框架的文章：
http://www.cnblogs.com/sheva/archive/2006/02/23/336520.html

Sheva

这本书其实主要作者是Ian Griffiths，而非Chris Sells.

Sheva

我个人认为OpacityMask应该翻译成：通过用OpacityMask属性指定的画刷的alpha通道值来遮掩此元素的alpha通道值。因为OpacityMask其实就是用两个alpha通道值来进行&运算。

Sheva

目前WPF/E版本提供的功能非常有限！

Sheva

我觉得你可以把两个图片合成一个图片然后将他作为3D模型的材料。这种方法也行可以解决你的问题，你可以通过如下方法来把两个图片合成一个图片：
<DrawingImage>
<DrawingImage.Drawing>
<DrawingGroup>
<ImageDrawing ImageSource="E:\2.jpg"/>
<ImageDrawing ImageSource="E:\2.jpg" Rect="0,0,60,60"/>
</DrawingGroup>
</DrawingImage.Drawing>
</DrawingImage>

Sheva

to:叶漂
你可以与梁晶联系，他会给你一份作译者信息登记表。

Sheva

to:Dflying Chen
相信我们会有合作的机会的。

Sheva

to:Dflying Chen
四个人一起翻译是很难保证翻译的质量，但是大家很多都是拿业余时间翻译的，在出版社规定好进度的情况下，也只能这样了。不知道Dflying Chen你对这本书感不感兴趣，如果感兴趣，可以让你一个人翻的:)

Sheva

to:Renard
从个人角度看，我更喜欢Ian Griffiths和Chris Sells写的《Programming Windows Presentation Foundation》，Ian Griffiths真是大师级的人物，我的很多WPF的编程的问题都是他给解决的，我和他经常在MSN交流WPF的很多方面的问题，感觉这个人好像无所不知。而且Ian Griffiths写书的风格是不仅要教会你编程技巧，而且还会告诉你很多WPF的内在实现机理。

Sheva

to:冬冬
应该说工作量相当大的，因为Charles Petzold的这本书听说有一千多页呀。如果你感兴趣的话，可以写Email给梁晶(fordin@gmail.com)

to:atempcode
不管怎么说，翻译别人的作品，翻译得再好也无法达到原作的水平，我以前翻译过一本书中的几章内容，在很大程度上可以说我是在糟蹋原作:)
不管怎么说，真心希望广大的高手请来应征。

Sheva

re:维生素C.NET
我对atlas没有任何接触,但是微软除了在标识语言XAML上借鉴了许多XHTML,其他的很多WPF概念都是全新的.

Sheva

.NET is not the hammer, and everything else the nail, just right tool for the right job.

Sheva

98%的问题我还是能非常准确的回答了，但是这并不意味着我精通.NET了。如果要说精通.NET，那么我们应该要掌握的是:
1. OOP.
2. Common Type System(Types and Instances in .NET).
3. Virtual Method dispatch and its performance implication.
4. Value Type and Reference(boxing and unboxing).
5. Mechanism and concepts applied in Automatic garbage collection.
6. XML manipulation.
7. Text manipulation.
8. Threading in .NET.
9. Asynchronous method dispatch in .NET.
10. CAS(Code Access Security)
11. Exception in .NET.
12. COM interop & P/Invoke
还有其他等等方面的内容。还有有人说所有精通.NET的人对COM都应该是精通的，这句话我不敢苟同。COM和CLR在某种程度上是大相径庭的，可以说没有任何联系。这点在Don Box的Essential .NET Common Language Runtime里面已经提及到了。可以说对于一个重来没有编写过COM组件的人来说，学习.NET并不会有任何的障碍。这个我是从我的个人感受来说的。

Sheva

@装配脑袋
如果有更高明的方法，不如分享给大家，但是我个人认为你在回复中举的那个例子不足以让人信服。

[quote]
还是分开回复吧。虚函数起作用便是在运行时，因此要求运行时类型必须匹配。而约束则是一个编译期检查，它只确保声明类型匹配。怎么说呢，假设有这样一个功能

public void Free<T>(T obj) where T : IDisposable
{
　　if (obj != null) obj.Dispose();
}

看起来很合理，只有实现IDisposable的才能Free。现在我们有一个地方用到了这个功能，但是声明类型却是MarshalByRefObject:

void SomeFunction(MarshalByRefObject obj)
{
　　Free(obj); //编译错误
}

很显然，MarshalByRefObject本身并没有实现IDisposable，所以编译不过，但是并不表明运行时那个类型不能 Dispose。要想编译通过，还是得进行强转。既然这样要泛型做什么呢？所以这里的错误就是将本该由OO来做的事情交给了泛型。那个约束明显是不必要的，应该这样写：

public void Free(IDisposable obj)
{
　　if (obj != null) obj.Dispose();
}

许许多多的使用接口约束的地方，其实不过是想使用那个接口而已，根本不需要约束。真正的泛型，需要对类型开放，像约束这种东西，不知不觉就约束你的抽象力。
[/quote]

因为你所说的这两种方法当把一个MarshalByRefObject的形参传给SomeFunction方法或是Free方法的时候都是会出现编译时错误的，这点是没有任何区别的。而且后一个方法也就是你所推荐的方法在运行时的时候会引入动态类型转换，因为你是在调用接口函数，从性能上来讲反而没有第一种用约束的好。
不知你有什么真知灼见？

Sheva

CodeProject上有一篇文章，讲述怎样用泛型来实现类型参数的计算：
http://www.codeproject.com/csharp/genericnumerics.asp

Edit:我晕，把URL给弄错了:)
Sheva

So, you've been using computer for nearly ten years?
Then you should be older than me:)

Edit: It's a great article, well done!!, but just one suggestion for you, you'd better use the phrase "top-down approach" or "top-down perspective" rather than "top-down scheme" in your original article:-)

Sheva

@windwolf
你说的那种不能叫做重写(overriding)，只能算是一种隐藏基类相同签名方法的一种方式，而且这种方式在没有必要的时候最好不要用。这和重写的概念是完全不一样的。

Sheva

Re: Maurits:
OMG, I am wrong again. I have a really bad regex reference book at hand, this teachs me again another famous old sayings:
Never fully trust what the book says.

Sheva

@wzq:
是把Dispose(Boolean disposing方法设计为虚函数，而不是IDisposable.Dispose()方法，不管是我的这种实现方法还是双鱼座的实现方法，都需要一个虚函数，这点是一样的。而且GC.SuppressFinalize(this)这个方法只在IDisposable.Dispose()方法里面调用，只调用一次。

Sheva

@双鱼座
“我的代码如果你看不懂就好好看，总有一天你会看懂的”
这样说话名摆得不想交流嘛！
一切尽在不言中！

Sheva

@双鱼座
“你不能拿BCL的代码说事儿，BCL可以调用GC的内部方法，以达到最高的性能。你行吗？”
呵呵，首先你得明白在CLR或是BCL里面没有什么所谓的secret APIs,BCL的类和你自定义的类没有任何区别，唯一的区别就在于BCL是微软写的，而自定义类是你自己写的。

你刚才的那个代码我却是没有看懂。
private void Dispose(bool disposing)
{
ReleaseUnmanageResources();
if (disposing)
{
GC.SuppressFinalize(this);
}
}
也就是说不管disposing参数的值是什么，ReleaseUnmanageResources()都将回被调用来释放资源，不知道是你写错了，还是你本来就没有明白GC的机制。当然我知道你确实是把ReleaseUnmanageResources()方法定义为虚函数了。

“其特殊之处就在于Dispose中需要通知GC一些释放资源的策略”
这个我也没有明白，你所说的策略是什么策略呀。首先我要告诉你当你使用了dispose模式时，你就告诉了GC，非托管资源的释放操作完全由你负责，而不是由Finalize方法负责，IDisposable.Dispose()方法和Finalize方法最大的不同就在于当你需要释放非托管资源的时候，你直接调用dispose方法来释放资源，而也就是说这种释放资源的操作是可控的，是deterministic的，而Finalize就不一样了，首先你不能直接调用该方法来释放非托管资源，因为这个方法只有GC才能调用，而如果你是靠GC来释放资源的话，这个释放操作就是不可控制的，因为GC只有当generation one满的时候才会进行释放资源的操作，而这种释放资源的方式从性能上来讲的话是不好的，因为GC首先会检查你的类是否定义了Finalize方法，然后把该类的一个root放到Finalization List里面，然后当下回再进行垃圾收集的时候，它才调用Finalize方法来释放资源，当Finalize方法被调用以后，你的这类就不能再被访问了。也就是说对于定义了Finalize 方法的类来说，GC需要进行两次垃圾收集才能对其释放非托管资源。这个楼主已经讲到，我这里只是再罗嗦两句。

还有，我还得必须指出的是咱们千万不要说BCL的类性能优秀是因为它可以访问一些CLR的内部APIs,这种猜想，这种假设是完全不符合逻辑，是没有任何根据的。但是我不得不承认有些BCL类确实和咱们的自定义类是不一样的，比如String, Int32, Int64, Delegate等，这些内建的类是非常特殊的类。他们之所以特殊是因为这些类要么和某一.NET编程语言息息相关，要么就是和CLR的内部操作息息相关，所以对这些类的性能，MS是做了特殊的工作的。但是对于其他的许许多多类比如我刚才提到的 FileStream类就和我们自定义的类没有任何区别。

BTW:言词有激烈之处，或是在某些概念上出错了，请大家斧正。


Sheva

我在上面已经给起了一个名字，现在再重复一遍：Codomatic
意思就是 code automatic，我觉得这个名字还是比较不错的，呵呵！！有点自卖自夸的感觉了。

如果中标，给我发一个信息，然后在你的软件里面说明这个名字是我起的就行了。呵呵，只为名，不为财！！！！！！
footballism@gmail.com

Sheva

我发现一个问题，原来BCL也是这样用Dispose()方法的：
public virtual void Close()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}
而我喜欢这样用：
public virtual void Close()
{
GC.SuppressFinalize(this);
this.Dispose(true);
}
两者区别就在于当Dispose(disposing)方法抛出一个异常的时候，也就是说该方法没有完成资源的释放，你是否希望让GC调用Finalize()方法来释放资源。
呵呵！！！这回我找到证据了，看来以后应该这样用dispose模式才对。

Sheva

@双鱼座
你刚才所描述的“千万不要将Dispose方法设计成虚方法，也根本不存在base.Dispose()这样的调用”我没有理解。

把Dispose(Boolean disposing)方法设计成虚函数是为了基类能通过重写这个方式实现自己的dispose逻辑。而且base.Dispose(disposing)这样调用也没有任何错误，难道你的基类就不用释放资源了吗？
在BCL里面FileStream类是这样实现dispose模式的：
protected override void Dispose(bool disposing)
{
try
{
if (((this._handle != null) && !this._handle.IsClosed) && (this._writePos > 0))
{
this.FlushWrite(!disposing);
}
}
finally
{
if ((this._handle != null) && !this._handle.IsClosed)
{
this._handle.Dispose();
}
this._canRead = false;
this._canWrite = false;
this._canSeek = false;
base.Dispose(disposing);
}
}

public virtual void Close()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}

public void Dispose()
{
this.Close();
}

~FileStream()
{
if (this._handle != null)
{
this.Dispose(false);
}
}
这样该能说明问题了吧！！！！！！！！！！！！！

Sheva

其实了解boxing和unboxing对提高你的程序的性能是有很大帮助的。
比如:
Int32 x = 12345;
System.Console.WriteLine(x);
和
Int32 x = 12345;
System.Console.WriteLine(x.ToString());
这两行代码虽然结果一样，但是第一个例子会产生boxing操作，而第二个例子则不会。

Sheva

public void Dispose()
{
// do something to release my unmanaged resource
ReleaseMyResource();
base.Dispose();

// tell gc not to call Finalize()
GC.SuppressFinalize(this);
}
楼主喜欢这样用呀，我的习惯和楼主不同，我喜欢这样用：
public void Dispose()
{
// tell gc not to call Finalize()
GC.SuppressFinalize(this);

// do something to release my unmanaged resource
ReleaseMyResource();
base.Dispose();

}

Sheva

Naming recommendation:
Your application can be named Codomatic which stands for Code Automatic. apparently this name elagantly fits into the real purpose of your application, since what your application does is to automatically generate the plumbing code, so other developers don't have to rewrite those repetitive and tedious data base accessing code(correct me if I'm wrong here)

Codomatic! Codomatic! Codomatic!
if you don't pick up this name, I will use this fancy name for my own ORM application:-)

Sheva

To: ccBoy
谢谢你的鼓励！！！

Sheva

不知道那个B看了后，会有什么感想，呵呵！！！

Sheva

to:悠悠我心
楼主说的是ASP.NET设计时设计器的序列化机制。IMHO这和ViewState的序列化机制毫无关系。

Sheva

Open cnblogs English Correction Engine.

"We Care About Your Felling" should be "We Care About Your Feeling".

Shut down cnblogs English Correction Engine.

Sheva

我觉得博客园的代码既然是基于.Text,那就应该把Scott Watermasysk的logo放在上面，不然人家会不高兴的:-)

Sheva

U2U好好努力，我支持你!!!在国外，十五六岁的高中生编写程序，建立网站的比比皆是，而在国内就寥寥无几了。
当然首先你要能保证在完成自己学习任务的基础上，在自己的课余时间来学习编程。不管怎么说，在中国，上大学还是得看你能考多少分。

Sheva

不好意思，发现几个错别单词，呵呵！！！

Sheva