100分求教，事件是否一定得由方法引发？刚才发的那个分数太少了。呵呵...

[robter5611]

.Net Framework文档上说的是：

事件功能是由三个互相联系的元素提供的：提供事件数据的类、事件委托和引发事件的类。.NET Framework 具有命名与事件相关的类和方法的约定。如果想要您的类引发一个名为 EventName 的事件，您需要以下元素。

持有事件数据的类，名为 EventNameEventArgs。该类必须从 System.EventArgs 导出。
事件的委托，名为 EventNameEventHandler。
引发事件的类。该类必须提供：
事件声明。
[C#]
public event EventNameEventHandler EventName;

[Visual Basic]
Public Event EventName As EventNameEventHandler

引发事件的方法，名为 OnEventName。

于是按照这个步骤我写了个事件。为简单点，没有事件数据。源代码如下：

using System;

namespace ConsoleApplication1
{
/// <summary>
/// Class1 的摘要说明。
/// </summary>
///
public delegate void MyEventEventHandler(object source);
public class MyEventClass
{
public event MyEventEventHandler MyEvent;
public void OnMyEvent()
{
if(MyEvent != null)
MyEvent(this);
}
}
class Class1
{
/// <summary>
/// 应用程序的主入口点。
/// </summary>
[STAThread]
static void Main(string[] args)
{
//
// TODO: 在此处添加代码以启动应用程序
//
MyEventClass c = new MyEventClass();
c.MyEvent +=new MyEventEventHandler(c_MyEvent);
c.OnMyEvent();
}

private static void c_MyEvent(object source)
{
Console.WriteLine("成功引发事件！");
}
}
}

运行没问题。
成功引发了事件。
但有一个问题不明白，就是

　　　　事件是否一定得由方法引发？

如果将程序中　c.OnMyEvent();　这一行去掉则不能引发事件。

但我看WINDOWS应用程序中，添加一个 Button,双击之，自动添加了一个Click事件，且未用任何方法来引发。运行也没问题。

所以请教各位老大。

[SimerJoe]

事件是否一定得由方法引发？

这句话要看怎么理解了
在C#里面应该这么说：可以由方法引起，也可以由“属性”的改变引起。（其实"属性"本质上就是一个方法）

详细回答这个问题可能需要写上千字了，由于我不打算写上千字，所以我打算简单的回答这个问题。

记得C++里面的函数指针吗？知道函数地址以后就可以调用函数了。
在C#里面的“事件”其实就是一个“方法”，要引起事件，就必须调用事件。
那么在哪里调用呢？只有可能是方法或者是属性。
省略代码若干行。。。。。。。

那么在调用事件的时候好像又和调用方法有一些不同，应为有些时候一行调用事件的代码可以引起若干个事件的触发。其实就是执行了若干个放在不同地方的方法。
在这里需要提到委托了，委托其实就是接口的一种表现形式。
一个委托通常都定义了一些参数和〉=1个方法名，而且要求这些方法的参数是一样的（或者说可以隐式转换的）。其实这样做就是取得这些方法的地址和方法的参数，当你使用委托的时候它就会一个一个来调用这些方法。
省略代码若干行。。。。。。。

其实所有这些都是方法和方法签名以及一个保存参数和方法地址的数组可以做到的，楼主有兴趣可以实践一下。

附：本人应为项目需要已经离开.net世界半年多了，现在搞java,好怀念微软所有简单易用的咚咚尤其是DataSet ；）

[以专业开发人员为伍]

搂主对号入座的时候坐错了位置了！！

设计器自动为控件创建的事件代码，其实是你的例子中的 c_MyEvent 方法，是响应事件的方法代码，不是到控件上面增加了一个事件。而类似 c.OnMyEvent() 的代码早在控件中写好了，你的程序无法也没有去创建和改变它。

[以专业开发人员为伍]

事件机制是一个方法队列，如果是空的就什么也不做，否则就顺序执行别人增加到队列中的每一个方法。

[以专业开发人员为伍]

所以事件不是由方法引发，而是由方法响应。把思路倒过来就能理解没有方法也没有关系。

[ivorstar]

肯定是由方法引发的，像OnClick那种是控件内置的方法啊，你自己的类要响应事件的话，除非继承原有的控件，否则肯定要自定义事件，自己写方法引发事件。

[mark44404]

SimerJoe(浪月) 所说的观点是基于CLR中事件的工作机制的一个好的理解

扩充地说，，事件使得比如Button类定义了一个名为Click的事件，当对象被点击时，应用程序中的一些对象可能希望能够收到通知、并执行一些动作。当事件作为一种类型成员，事件使得这种交互成为可能。具体地说，定义一个事件成员，就意味着类型为我们提供了一下三种能力：
1、允许对象登记该事件；
2、允许对象对该事件实行注销；
3、允许定义事件的对象得以维持一个登记对象的集合，并在某特定的事情发生时通知这些对象。
CLR的事件模型建立在委托这一机制之上 ，而委托则可以为我们提供一种类型安全的方式来调用回调方法。

[Ivony]

OnEventName方法最大的作用在于
if ( someevent != null )
someevent( params );


因为如果不这样写，就有可能抛出异常。。。。这是谁都不愿意看到的。

但实际上我认为这是垃圾代码。。。

[robter5611]

多谢各位老大，兄弟还是不太明白。
能否说得简单点？
就一个问题：
能否想内置控件那样不需方法即可响应事件？

[zgtt]

xuexi

[robter5611]

Ivony兄，那Button控件的Click事件由干什么来触发的呢？没看见触发Click的代码啊。

[速马]

// 那Button控件的Click事件由干什么来触发的呢？没看见触发Click的代码啊
Windows消息循环

[cnazi]

WINDOWS应用程序中，添加一个 Button,双击之，自动添加了一个Click事件，且未用任何方法来引发。

Windows消息循环,这是最常见的消息触发

[zeusvenus]

普通的事件应该来说是方法引发的，特殊的已经经过消息触发内置处理。

[Ivony]

多谢各位老大，兄弟还是不太明白。
能否说得简单点？
就一个问题：
能否想内置控件那样不需方法即可响应事件？



首先，触发事件必须由代码来完成，系统不会帮你触发任何事件。所以讨论事件是不是必须由方法触发是没有任何意义的，正确的说法是事件必须由代码触发，而实际上所有的代码都必须写在方法（或者属性、索引器）里，否则是语法错误。区别仅在于这个代码是你写的还是.NET Framework写的。

事件的响应必须由特定签名（方法的签名指方法的参数列表和返回值类型和顺序）的方法完成。这个特定的签名就是由事件的委托约定的，最常见的是EventHandler，即无返回值，接受一个object和一个EventArgs参数的方法。

内置控件如何不需要方法响应事件了？！

[robter5611]

多谢各位老大。结了。

[Ivony]

WINDOWS应用程序中，添加一个 Button,双击之，自动添加了一个Click事件，且未用任何方法来引发。


Form内部实现的代码截获Windows发来的消息，将其分析处理后传播到相应的子控件，子控件根据消息触发不同的事件。

大概就是这样。