它只是我，还是事件只是伪装？ [英] Is it just me, or are events just Subs in disguise ??

问题描述

您好，


我正在学习一本关于VB.net Win应用程序的书，我正在阅读有关

事件和代表和筹集活动。


这只是我，或者这不仅仅是装扮成其他东西吗？


我的意思是，对于一，代表指向潜艇，所以当你打电话给代表时，

为什么不直接打电话给sub而不打扰添加额外的

代码涉及添加委托？


至于事件，在宣布一个事件之后你可以在

合适时提高它。这不就是调用子或函数吗？


原谅我，如果我错过了生活在这里改变的东西，但我只是

没有得到它！


任何人都可以帮助澄清用户定义事件的重要性吗？


BTW，我确实得到了它当控件引发事件时。就像点击事件为

一个按钮。但是将事件添加到您自己的类似乎就像

添加标准子。


-Nick

解决方案

你好Nicky，


你是否错过了一般关于活动和代表的重点。


两者的美妙之处在于它们不需要呼叫者。使用传统的

sub，调用过程必须知道sub存在并调用它。使用

事件时，调用者只需注册该事件，并在有兴趣发生时调用指定的（通过

委托）方法。


模式通常称为Observer / Observable。当你问为什么

不只是在一个班级而不是他们提出事件时，那么请问你自己如何使用这种方法，一个表格知道什么时候一个按钮a是

点击。


使用事件/代表，表单只需注册click事件，然后

然后分配一个方法（具有与代表匹配的签名）以处理该事件，何时和/或是否发生该事件。使用你建议使用sub的方法只需

，表单必须不断轮询按钮以找出

是否已被点击或按钮必须知道表格将在开发时存在，并且知道该表格中的哪种方法可以在事件时调用
。发生。


与事件驱动模型的去耦合优雅相比，这很快变得完全混乱。


代表们是一个完整的学科领域。事件的基础是：它们允许任何与委托签名匹配的方法

和用于处理事件的事件的寄存器。有了你的想法，开发人员就必须知道在课程编写时对每个特定事件感兴趣的每个课程，并且知道哪些是
$该类中的b $ b方法在该事件的情况下调用。 ......这是一个非常复杂和浪费的小项目，不可能是大型项目或组件开发。


代表在允许扩展给定类运行时行为方面非常强大......以不必要的方式借贷

本身用于子类化....回调方法/异步开发等。


我认为最好的方法是发现为什么需要事件是尝试通过你的
来执行事件驱动的操作潜意识。你会很快

发现事件驱动型号的好处。

hth

Richard


" Nicky Smith" < NI *** @ yahoo.dk>在消息中写道

news：ru ******************************** @ 4ax.com ...

你好，

我正在学习一本关于VB.net Win应用程序的书，我正在阅读有关
事件和代表和筹集活动。

只是我，或者这不仅仅是装扮成其他东西吗？

我的意思是，对于一个，代表指向潜艇，所以当你给一个代表打电话时，为什么不直接打电话给sub而不打扰添加额外的代码呢？

至于事件，在宣布一个事件之后你适当时可以提高它。这不就像召唤子或功能一样吗？

如果我错过了生活在这里改变的东西，请原谅我，但我只是没有得到它！

任何人都可以帮助澄清用户定义事件的重要性吗？

顺便说一句，我确实在控件引发事件时得到它。就像按钮的Click事件一样。但是将事件添加到您自己的类似乎就像添加标准子类一样。

-Nick

< blockquote>


事件基于发生的事情运行子程序。如果您在编写类库时添加了事件来通知用户某些事情。对于

示例，定期检查电子邮件消息的类会在收到消息时提出一个事件。


代表是回调函数。使用它们进行api回调

函数或你想在后台运行的东西。例如，我从一个网站

服务中检索大量数据时，
将使用委托。这样它可以运行后台而不是锁定

计算机。另一个例子是enumwindows api电话


肯

----------------


" Nicky Smith" < NI *** @ yahoo.dk>在消息中写道

news：ru ******************************** @ 4ax.com ...

您好，


我正在学习一本关于VB.net Win应用程序的书，我正在阅读关于

活动和代表以及举办活动。


这只是我，还是这不仅仅是装扮成其他东西？


我的意思是，对于一个，代表指向潜艇，所以当你打电话给代表时，

为什么不直接打电话给sub而不打扰添加额外的

代码涉及添加代表吗？

至于事件，在宣布事件后你可以在

适当时提高它。这不就是调用子或函数吗？


原谅我，如果我错过了生活在这里改变的东西，但我只是

没有得到它！


任何人都可以帮助澄清用户定义事件的重要性吗？


BTW，我确实得到了它当控件引发事件时。就像点击事件为

一个按钮。但是将事件添加到您自己的类似乎就像

添加标准子。


-Nick

On Sun，2004年9月19日10:29:46 +1200，Richard Myers

< ri ************** *******@basd.co.nz>写道：

尼基，

你是否错过了关于活动和代表的重点。

美丽的两者都是他们不需要来电者。使用传统的子程序，调用程序必须知道sub存在并调用它。通过
事件，调用者只需注册事件，并在感兴趣的事情发生时调用指定的（通过
委托）方法。

模式更多通常称为Observer / Observable。当你问为什么
不只是在课堂上而不是他们提出事件时，那么请问自己，当使用这种方法时，表单会知道点击按钮a的时间。


好​​吧，就像我说的那样，我知道，并且看到控制事件中的逻辑。

（按钮和其他图形控件，以及非图形控制这样的

作为计时器）。这些是VB和windows

编程的日常事实，但是这本书（来自MSPress的MCAD Windows应用程序）建议

进行银行帐户课程并在帐户中筹集活动

透支。即当账户进入负数时。当生成任何

活动时，通过简单检查余额即可轻松处理这种类型的

行为，即：增加或撤回资金。

引用本书：


声明事件后，当指定事件发生时，您可以在代码中将其提升。例如，您可能有一个组件

代表一个银行账户，只要余额低于零，就可以提高透支事件

。

当然在VB中有事件，整个VB系统基于

事件，但书中的陈述似乎有问题。


我开始认为这可能只是一个不好的例子。


使用事件/委托，表单只需注册click事件，然后分配方法（具有与代表匹配的签名）处理该事件，何时和/或是否发生。使用你建议使用subs的方法，表单必须不断轮询按钮以找出是否已被点击或按钮必须知道表格将存在
在开发时，知道该形式中的哪种方法在事件时调用。发生。

与事件驱动模型的脱离优雅相比，这很快变得完全混乱。

代表们是一个完整的主题领域。事件的基础是它们允许任何与委托签名匹配的方法和事件的寄存器用于处理事件。根据您的想法，开发人员必须知道在编写类时对特定事件感兴趣的每个类，并知道该类中的哪个方法可以调用该类那件事。 ......在一个小项目中非常复杂和浪费，不可能在大型项目或组件开发中使用。

代表在允许扩展方面非常强大给定类的运行时行为...以一种不必要的方式借给自己的子类化....回调方法/异步开发等。

我想的最好方法你要发现为什么事件是必要的是尝试通过你的想法来执行事件驱动的操作。您将很快发现事件驱动模型的好处。



理查德

尼基史密斯 < NI *** @ yahoo.dk>在消息中写道
新闻：ru ******************************** @ 4ax.com .. < blockquote class =post_quotes>你好，

我正在学习一本关于VB.net Win应用程序的书，我正在阅读有关
事件和代表以及举办活动的部分。

这只是我，或者这不仅仅是装扮成其他东西吗？

我的意思是，对于一个，代表指向潜艇，所以当你打电话给委托，
为什么不直接调用sub并且不需要添加额外的代码来添加代理？

至于事件，在声明事件后你可以在事件发生时提出它
合适。这不就像召唤子或功能一样吗？

如果我错过了生活在这里改变的东西，请原谅我，但我只是没有得到它！

任何人都可以帮助澄清用户定义事件的重要性吗？

顺便说一句，我确实在控件引发事件时得到它。就像按钮的Click事件一样。但是将事件添加到您自己的类似乎就像添加标准子类一样。

-Nick

Hello,

I''m studying a book on VB.net Win apps, and I''m reading a section on
events and delegates and raising events.

Is it just me, or is this not just subs dressed up as something else?

I mean, for one, delegates point to subs, so when you call a delegate,
why not just call the sub dierectly and not bother adding the extra
code involved adding the delegate?

As for events, after delclaring an event you can raise it when
appropriate. Isn''t this just the same as calling a sub or function?

Forgive me if I''m missing something life changing here, but I just
don''t get it!

Can anyone help clarify the importance of user-defined events?

BTW, I do get it when controls raise events. Like the Click event for
a button. But adding events to your own classes seems exactly like
adding a standard sub.

-Nick

解决方案

Hi Nicky,

Yep you are missing a major point about events and delegates in general.

The beauty of both is that they dont require a "caller". With a traditional
sub the calling procedure has to know the sub exists and call it. With an
event the caller simply registers for the event and has a specified (via a
delegate) method(s) called when something of interest happens.

The pattern is more commonly called Observer/Observable. When you ask why
not just have subs in a class instead of them raising events, then ask
yourself how, when using this method, would a form know when a button a is
clicked.

Using events/delegates the form simply registers for the click event and
then assigns a method (with a signature matching the delegate) to handle
that event, when and/or if it occurs. With the method you suggest of just
using subs, the form would have to continously poll the button to find out
whether it had been clicked or the buttons would have to know the form would
exist at the time of development and know which method within that form to
call when an "event" occurs.

This quickly becomes a complete mess when compared with the de-coupled
elegance of the event driven model.

Delegates are a whole subject area unto themselves. The basics with respect
to events is that they allow any method that matches the delegate signature
and registers for the event to be used to handle the event. With your subs
ideas a developer would have to know every class that would ever be
interested in a specific event when the class is written and know which
method within that class to call in the case of that event. ... which is
extremely complex and wasteful in a small project and impossible n large
projects or with component development.

Delegates are exceptionally powerful in terms of allowing the extension of a
given classes runtime behaviour... in a manner not neccessarily lending
itself to subclassing.... callback methods/asynchronous development etc.

The best way i think for you to discover why events are neccessary is to try
to perform an event driven operation via your subs idea. You''ll quickly
discover the benefits of the event driven model.
hth
Richard

"Nicky Smith" <ni***@yahoo.dk> wrote in message
news:ru********************************@4ax.com...

Hello,

I''m studying a book on VB.net Win apps, and I''m reading a section on
events and delegates and raising events.

Is it just me, or is this not just subs dressed up as something else?

I mean, for one, delegates point to subs, so when you call a delegate,
why not just call the sub dierectly and not bother adding the extra
code involved adding the delegate?

As for events, after delclaring an event you can raise it when
appropriate. Isn''t this just the same as calling a sub or function?

Forgive me if I''m missing something life changing here, but I just
don''t get it!

Can anyone help clarify the importance of user-defined events?

BTW, I do get it when controls raise events. Like the Click event for
a button. But adding events to your own classes seems exactly like
adding a standard sub.

-Nick

Hi,

Events run a subroutine based on something happening. If you were
writing a class library you add events to notify the user of something. For
example a class that was periodically checking for email messages would
raise an event when a message is recieved.

Delegates are callback functions. Use them for api callback
functions or something you want to run in the background. For example I
would use a delegate when retrieving large amounts of data from a web
service. This way it can be run the background and not lock up the
computer. Another example would be the enumwindows api call

Ken
----------------

"Nicky Smith" <ni***@yahoo.dk> wrote in message
news:ru********************************@4ax.com...
Hello,

I''m studying a book on VB.net Win apps, and I''m reading a section on
events and delegates and raising events.

Is it just me, or is this not just subs dressed up as something else?

I mean, for one, delegates point to subs, so when you call a delegate,
why not just call the sub dierectly and not bother adding the extra
code involved adding the delegate?

As for events, after delclaring an event you can raise it when
appropriate. Isn''t this just the same as calling a sub or function?

Forgive me if I''m missing something life changing here, but I just
don''t get it!

Can anyone help clarify the importance of user-defined events?

BTW, I do get it when controls raise events. Like the Click event for
a button. But adding events to your own classes seems exactly like
adding a standard sub.

-Nick

On Sun, 19 Sep 2004 10:29:46 +1200, "Richard Myers"
<ri*********************@basd.co.nz> wrote:

Hi Nicky,

Yep you are missing a major point about events and delegates in general.

The beauty of both is that they dont require a "caller". With a traditional
sub the calling procedure has to know the sub exists and call it. With an
event the caller simply registers for the event and has a specified (via a
delegate) method(s) called when something of interest happens.

The pattern is more commonly called Observer/Observable. When you ask why
not just have subs in a class instead of them raising events, then ask
yourself how, when using this method, would a form know when a button a is
clicked.
Well, as I said, I do know about, and see the logic in control events.
(buttons and other graphical controls, and non-graphical controls such
as the timer). These are an everyday fact of VB and windows
programming, but the book (MCAD Windows Apps from MSPress) suggests
making a bank account class and raising an event if the account is
overdrawn. namely when the account goes in minus. That type of
behaviour is easly handled by a simple check to the balance when any
activity is generated, ie: adding or withdrawing funds.

To quote the book:

Once an event is declared, you can raise it in code when the
designated event occurs. For example, you might have a component that
represents a bank account, which could raise an Overdrawn event
whenever the balance falls below zero.

Of course there are events in VB, the whole VB system is based on
events, but that statement from the book seems questionable.

I''m starting to think that this may be just a bad example.

Using events/delegates the form simply registers for the click event and
then assigns a method (with a signature matching the delegate) to handle
that event, when and/or if it occurs. With the method you suggest of just
using subs, the form would have to continously poll the button to find out
whether it had been clicked or the buttons would have to know the form would
exist at the time of development and know which method within that form to
call when an "event" occurs.

This quickly becomes a complete mess when compared with the de-coupled
elegance of the event driven model.

Delegates are a whole subject area unto themselves. The basics with respect
to events is that they allow any method that matches the delegate signature
and registers for the event to be used to handle the event. With your subs
ideas a developer would have to know every class that would ever be
interested in a specific event when the class is written and know which
method within that class to call in the case of that event. ... which is
extremely complex and wasteful in a small project and impossible n large
projects or with component development.

Delegates are exceptionally powerful in terms of allowing the extension of a
given classes runtime behaviour... in a manner not neccessarily lending
itself to subclassing.... callback methods/asynchronous development etc.

The best way i think for you to discover why events are neccessary is to try
to perform an event driven operation via your subs idea. You''ll quickly
discover the benefits of the event driven model.

hth
Richard

"Nicky Smith" <ni***@yahoo.dk> wrote in message
news:ru********************************@4ax.com.. .

Hello,

I''m studying a book on VB.net Win apps, and I''m reading a section on
events and delegates and raising events.

Is it just me, or is this not just subs dressed up as something else?

I mean, for one, delegates point to subs, so when you call a delegate,
why not just call the sub dierectly and not bother adding the extra
code involved adding the delegate?

As for events, after delclaring an event you can raise it when
appropriate. Isn''t this just the same as calling a sub or function?

Forgive me if I''m missing something life changing here, but I just
don''t get it!

Can anyone help clarify the importance of user-defined events?

BTW, I do get it when controls raise events. Like the Click event for
a button. But adding events to your own classes seems exactly like
adding a standard sub.

-Nick

这篇关于它只是我，还是事件只是伪装？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！