在這裡我們去掉了event關鍵字，改用純委托對象來實現。
而後，同樣建立一個上層的Demo程序來調用這個控件，同樣比之上一段代碼要作些許細微的調整：
namespace EventDemo
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
this.userControl11.MyEvent += new Ctrleven.UserControl1.MyEventHander(this.VirtualEvent);
}
public void VirtualEvent()
{
MessageBox.Show("委托仿真事件調用成功！");
}
}
}
看到區別了嗎？呵呵…… 此時InitializeComponent（）關於事件掛接的那句話已經不見了，因為這次的MyEvent並不是一個事件專用的委托對象，而是一個普通的委托實例對象，不會自動被C#的編輯器識別。所以，我在主窗口類的構造方法中人為添加了一句代碼：
this.userControl11.MyEvent += new Ctrleven.UserControl1.MyEventHander(this.VirtualEvent);
它的作用其實和上一段代碼中那句是相同的，就本質而言都是在一個類中操控另一個類的委托對象而已，只不過因為我們沒有嚴格按照C#中的事件聲明方式來實現事件機制，因此，這句代碼C#的編輯器不會很友好的替你生成，而是要靠你自己來寫。呵呵……
可見，程序運行的效果和上一段代碼大致相同。
在這裡，我想糾正大家的幾個誤區。平時，我經常聽到人們談論，說所謂委托就是將自己寫好的一段代碼作為參數傳入另一個方法中。沒錯，用委托的確可以實現類似的說法，比方說某一個方法的參數表中的一個參數是委托類型，這樣子的確是可以的。但是，可以實現這種效果的先決要素首先是我們可以利用委托來傳遞一段代碼（也就是一個方法）。所以說真正起到傳遞方法效果的不是方法中的參數，而是委托對象本身。使用委托對象本身來實現跨類、跨線程甚至跨空間傳遞方法，這種實現形式的使用頻率要比僅僅將委托作為參數，以實現將代碼傳入另一個方法這樣的實現形式來的高得多得多。
好，寫到這裡，我想應該可以稍微闡述一下我自己的觀點了。呵呵……
個人認為，委托最大的優勢所在就是——其兼有對象和方法二者的性質。我們既可以將一個委托實例對象作為對象來看待甚至操控，亦可以將其作為一個現成的方法來調用。（未完待續）
