sender是什么对象？
有这样一段代码
if   sender.commandname= "first "   Then
    lbtn2.commandname= "second "

else
    label1.text= "你单击了按钮2 "
    lbtn1.commandname= "first "
 
end   if
上面有好些都没有讲清楚

但按一般的情况来看，就看sender指的是什么   对象？

------解决方案--------------------
说的通俗一些，就是：

有一个叫做EventHandler 的家伙，他会告诉你（主程序），有一些事情发生了：这个事情是谁导致的呢？是某个object类型对象导致的，它用Source或Sender来表示。

所以，我们在程序中的事件处理函数就是依赖于这个东西实现的：比方说你点了一个按钮，程序怎么知道应该用哪个函数来处理这个动作呢？那么EventHandler 这个家伙会告诉程序： "button1(sender)被点击(e)了，请调用对应的处理函数 "。

再深入一层，这个过程实际上就是：你的动作被windows捕获，windows把这个动作作为系统消息发送给程序（可以看message结构），程序从自己的消息队列中不断的取出消息，并在消息循环中寻找对应的处理方式，这时message结构中的类似于sender和e的东东就起到了引导程序使用正确的处理函数的作用。

归根究底，这个sender和e及其一整套的处理方式，只不过是windows消息机制的另外一种表现罢了
------解决方案--------------------
但按一般的情况来看，就看sender指的是什么 对象？
————————————————————————————————————————
就像是“轮回转世”，它是一种许愿。

微软asp.net项目组大概觉得给每一个事件都规定非常明确的事件delegate定义太麻烦了，或者是从早在10几年前就流行的Windows VB Form编程继承下来的习惯，它定义了EventHandler这个delegate来使用“各种各样”事件。既然如此含糊，那么只能把Sender这个对象搞得含糊一些，而不能明名白白地定义，所以只能声明为比较“通用、含糊”的object。不过，所有对象都是从object继承的，因此这个参数实际上传递的是更为具体的类型的对象。
------解决方案--------------------
看一下
------解决方案--------------------
简单点说：就是激活那个事件的对象，比如Button_click(object sender,....)
sender就是指那个按钮对象。
------解决方案--------------------
引发事件的罪魁祸首
------解决方案--------------------
类似Delphi的Sender，事件的发起者
------解决方案--------------------
如果事情都如初学者所愿（而不计较真实的历史中的现实问题），那么所有的事件应该单独定义，并且往往sender都是非常明确的类型的，那时你就不会疑惑了。

可惜估计除非.net被淘汰，否则可能会一直维持这种混淆使用事件接口的状况下去，2012年也许能够让楼主体会到自己的怀疑实现了。