通常的事件格式是唯一的方法吗？ [英] Is the usual Event format the only way to go?
问题描述
由于我在这个NG中看到的强烈推荐，我所有的活动都是
形式：
公共事件高度变化（ByVal发送者为对象，ByVal e As
HeightChangeEventArgs）
其中：
Public NotInheritable Class HeightChangeEventArgs
继承EventArgs
....
我总是想知道是否需要这种格式，并认为我会研究
有一天。
今天我看到了一本高级的vb.Net书，它使用了以下活动：
Public Event HeightChanged （zz As String）
有没有理由比第二种形式更喜欢第一种形式？毕竟我用
定义了我喜欢的任何签名的其他方法。如果消费者知道发件人
必须是谁的时间，我可以想到没有
发送发件人的理由。更重要的是，当String将
时，必须维持一个班级。
我将不胜感激任何与此相关的评论。
特别是，你总是遵循规定的惯例吗？
谢谢
活跃，
约定只有在遵循时才有用。
.Net框架虔诚地使用这个惯例。因此，任何熟悉.Net事件的b $ b程序员都会熟悉你创建的事件。
当然，什么也没有阻止你使用
为你工作的任何事件签名。
Kerry Moorman
" active"写道：
由于强烈建议我在这个NG中看到我的所有活动都是
形式：
Public Event HeightChanged（ByVal sender As Object，ByVal e As
HeightChangeEventArgs）
其中：
Public NotInheritable Class HeightChangeEventArgs
继承EventArgs
....
我总是想知道对这种格式的需求并且想到我有一天会看到
。
今天我看到了一本使用以下事件的高级vb.Net书：
公共事件高度变化（zz为字符串）
有没有理由比第二种形式更喜欢第一种形式？毕竟我用
定义了我喜欢的任何签名的其他方法。如果消费者知道发件人
必须是谁的时间，我可以想到没有
发送发件人的理由。更重要的是，当String将
时，必须维持一个班级。
我将不胜感激任何与此相关的评论。
特别是，你总是遵循规定的惯例吗？
谢谢
感谢您的评论
" Kerry Moorman" < Ke ********** @ discussion.microsoft.com写信息
新闻：AF ****************** **************** @ microsof t.com ...
活跃，
约定仅在遵循时才有用。
.Net框架虔诚地使用此约定。因此，任何熟悉.Net事件的b $ b程序员都会熟悉你创建的事件。
当然，什么也没有阻止你使用
为你工作的任何事件签名。
Kerry Moorman
" active" ;写道：
>由于强烈建议我在这个NG中看到我所有的活动都是
形式：
Public Event HeightChanged（ByVal sender As Object，ByVal e As
HeightChangeEventArgs）
其中：
公共NotInheritable类HeightChangeEventArgs
继承EventArgs
....
我总是想知道这种格式的必要性，并认为有一天我会把它看成
。 />
今天我看到了一本高级的vb.Net书，它使用的事件如下：
Public Event HeightChanged（zz As String）
有什么理由可以选择第一种形式超过第二种？毕竟我用任何我喜欢的签名来定义其他方法。如果消费者知道发件人必须是谁的时间，我可以想到没有理由发送发件人。而且更重要的是，当String
做什么时必须维持一个班级。
我将不胜感激任何与此相关的评论。
特别是，你是否总是遵循规定的惯例？
active写道：
Public Event HeightChanged（ByVal sender As Object，ByVal e As
HeightChangeEventArgs）
我总是想知道是否需要这种格式，并认为有一天我会查看
。
今天我看到了一本高级的vb.Net书，它使用了以下事件：
Public Event HeightChanged（zz As String）
有没有理由比第二种形式更喜欢第一种形式？毕竟我用
定义了我喜欢的任何签名的其他方法。如果消费者知道发件人
必须是谁的时间，我可以想到没有
发送发件人的理由。
这就是论证的关键所在。
你今天写的代码怎么能知道谁或者什么可能会在未来的任何一点向它投掷
这个事件？
事件最常由控件引发，以便其他代码
（处理程序）可以对它作出反应，通常也会对发送
控件进行一些更改。例如，如果你点击一个按钮，你可能需要点击处理程序禁用按钮，直到它准备好再次执行它的
作业。如果没有发件人的参考，你就不能这样做 - 你不知道是谁b $ b不知道是谁送你的。
当然，你可能实际上并不需要这一切 - 如果Handler很简单
足够你不需要向发件人询问任何东西或做任何事情
它，那么精细;你的第二个，更短的语法将很好地完成这项工作...
，直到你将这个/一点点代码添加到Handler中/ do /
需要返回发件人...你必须开始重新编译
所有地方的所有内容都要将发件人参数添加回来...... ;-)
HTH，
Phill W.
Because of a strong recommendation I saw in this NG all my events are of the
form:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)
where:
Public NotInheritable Class HeightChangeEventArgs
Inherits EventArgs
....
I always wondered about the need for that format and figured I''d look into
it someday.
Today I saw an advanced vb.Net book that used events like:
Public Event HeightChanged(zz As String)
Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be. And more importantly, having to maintain a class when String would
do.
I''d appreciate any comments relating to this.
In particular, do you always follow the stated convention?
Thanks
active,
A convention is only useful if it is followed.
The .Net framework uses this convention religiously. Therefore, any
programmer familiar with .Net events will be familiar with events that you
create.
Of course, nothing is preventing you from using any event signature that
works for you.
Kerry Moorman
"active" wrote:
Because of a strong recommendation I saw in this NG all my events are of the
form:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)
where:
Public NotInheritable Class HeightChangeEventArgs
Inherits EventArgs
....
I always wondered about the need for that format and figured I''d look into
it someday.
Today I saw an advanced vb.Net book that used events like:
Public Event HeightChanged(zz As String)
Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be. And more importantly, having to maintain a class when String would
do.
I''d appreciate any comments relating to this.
In particular, do you always follow the stated convention?
Thanks
thanks for your comments
"Kerry Moorman" <Ke**********@discussions.microsoft.comwrote in message
news:AF**********************************@microsof t.com...active,
A convention is only useful if it is followed.
The .Net framework uses this convention religiously. Therefore, any
programmer familiar with .Net events will be familiar with events that you
create.
Of course, nothing is preventing you from using any event signature that
works for you.
Kerry Moorman
"active" wrote:
>Because of a strong recommendation I saw in this NG all my events are of
the
form:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)
where:
Public NotInheritable Class HeightChangeEventArgs
Inherits EventArgs
....
I always wondered about the need for that format and figured I''d look
into
it someday.
Today I saw an advanced vb.Net book that used events like:
Public Event HeightChanged(zz As String)
Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be. And more importantly, having to maintain a class when String
would
do.
I''d appreciate any comments relating to this.
In particular, do you always follow the stated convention?
Thanks
active wrote:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)
I always wondered about the need for that format and figured I''d look into
it someday.
Today I saw an advanced vb.Net book that used events like:
Public Event HeightChanged(zz As String)
Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be.And therein lies the crux of the argument.
How can code that you write /today/ know who or what might be throwing
this event at it at any point in the Future?
Events are most commonly raised by Controls so that other code
(Handlers) can react to it, usually making some change to the sending
Control as well. For example, if you click on a Button, you probably
want the Click handler to disable the button until it''s ready to do its
job again. Without a reference to the sender, you can''t do that - you
wouldn''t know who had sent you the event.
Of course, you may not actually need all this - if the Handler is simple
enough that you don''t need to ask the sender anything or do anything to
it, then fine; your second, shorter syntax will do the job nicely ...
until you add that /little/ bit of code into the Handler that /does/
need to go back to the sender ... and you have to start recompiling
everything all over the place to add the sender argument back in... ;-)
HTH,
Phill W.
这篇关于通常的事件格式是唯一的方法吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
