Event-Event calling

[Steve B.]

Is it good programming practice to call an event within an event?
I'm I creating recursion somehow somewhere? Does an event (e.g. send, e)
ever end?

I'm sorry, I'm not sure I know what I mean, however, I do know what ever it
is I should be aware of it.

currentcell_event(..)
{
..
..
moveLastGridcell_button(sender, e);
}

Steve

[Bruce Wood]

Technically, you can't raise an event from within an event... events
aren't language constructs. You can, however, raise an event from
within an event _handler_, and there's nothing wrong with that. Anyway,
that's quibbling, isn't it?

Is there anything wrong with raising an event from within an event
handler? No, there's nothing wrong with it at all. Just like
exceptions, you may want to transform events into other events. For
example, I wrote a bunch of Binding classes for use in my Windows
forms: they connect properties in my model class to controls on my
form. One of the kinds of binding that I created is an AndBinding. The
AndBinding subscribes to two xxxChanged events of my model, each
corresponding to a boolean property of the model. Whenever one of these
two properties changes, the model raises the xxxChanged event. If the
AndBinding finds that this makes the result of an "and" on the two
properties change its value, it in turn raises a "ValueChanged" event,
right from inside the event handler. In other words, it handles an
event from one object and then transforms that event into a different
event to be consumed by some other object.

Of course, if you create circular chains of events then your program
will die with a stack overflow when that event is raised (event
dispatch is just a method call, after all).

As well, there are some stylstic concerns. If you have lots of code
raising events from within event handlers then maybe you're trying to
pack too many smarts into your presentation code and need to take a
look at the Model-View-Controller software pattern. It's not
syntactically evil... it's just that if grows too much it can be
difficult to figure out what's going on.

[Nick Malik]

The primary reason that it isn't good to use events as a mechanism for
handling normal logic, is that events cost considerably more than simple
object calls.

Use events for error handling, never for logic that can be detected and
handled in another way.

In addition, there are many design patterns that will allow you to use a
flexible design that often sidesteps the need for event handlers to throw
custom events. Check out the Chain of Responsibility and the Command
patterns.

--- Nick

"Steve B." <St****@discussions.microsoft.com> wrote in message
news:92**********************************@microsof t.com...

Is it good programming practice to call an event within an event?
I'm I creating recursion somehow somewhere? Does an event (e.g. send, e)
ever end?

I'm sorry, I'm not sure I know what I mean, however, I do know what ever it is I should be aware of it.

currentcell_event(..)
{
.
.
moveLastGridcell_button(sender, e);
}

Steve

[Steve B.]

Thank you for both your comments. Based on your comments I think it's best if
I avoid the pratice, put the code in my interface and implement some of Mr.
Gamma's patterns

Thank you again --Steve

"Nick Malik" wrote:

The primary reason that it isn't good to use events as a mechanism for
handling normal logic, is that events cost considerably more than simple
object calls.

Use events for error handling, never for logic that can be detected and
handled in another way.

In addition, there are many design patterns that will allow you to use a
flexible design that often sidesteps the need for event handlers to throw
custom events. Check out the Chain of Responsibility and the Command
patterns.

--- Nick

"Steve B." <St****@discussions.microsoft.com> wrote in message
news:92**********************************@microsof t.com...

Is it good programming practice to call an event within an event?
I'm I creating recursion somehow somewhere? Does an event (e.g. send, e)
ever end?

I'm sorry, I'm not sure I know what I mean, however, I do know what ever

it

is I should be aware of it.

currentcell_event(..)
{
.
.
moveLastGridcell_button(sender, e);
}

Steve

[Bruce Wood]

I'm no guru, but I think that you're confusing events with exceptions.

Events don't cost considerably more than simple object calls. Raising
an event is a little bit more expensive than a simple method call
(there's a test for null, an for multicast events there is a walk down
a subscriber list). It's exceptions that introduce overhead and are
considerably more expensive than a method call.

The next statement, "Use events for error handling, never for logic
that can be detected and handled in another way," is what set me to
thinking that perhaps you're confusing events and exceptions. The
entire WinForms object model runs on events. ADO.NET makes heavy use of
events. The Model-View-Controller design pattern that I mentioned
explicitly calls on the programmer to _prefer_ events over using simple
method calls because it vastly simplifies the application (in those
cases in which the design pattern applies).

It's exceptions that you shouldn't use for normal program flow.
Exceptions and try...catch are universally acknowledged as costly and
best avoided when it's not unreasonable to do so.

The only problem I've ever had with using events was that of
unknowingly creating circular chains of events that caused my apps to
hang, which is why I went to Model-View-Controller design, because that
design clearly lays out the responsibilities of each software component
and avoids the kind of event chaos that frequently results from
grow-your-own event architectures.

[Steve B.]

Thanks Bruce

I've changed my ADO code to something like below. Circular chains was
exactly what I was afraid of before

Thank You
Steve

mycell1_event(..)
{
event ("mycell1");
}

mycell2_event(..)
{
event ("mycell2);
}

event (string cell)
{
if(cell == mycell1)
..
..
..
}
"Bruce Wood" wrote:

I'm no guru, but I think that you're confusing events with exceptions.

Events don't cost considerably more than simple object calls. Raising
an event is a little bit more expensive than a simple method call
(there's a test for null, an for multicast events there is a walk down
a subscriber list). It's exceptions that introduce overhead and are
considerably more expensive than a method call.

The next statement, "Use events for error handling, never for logic
that can be detected and handled in another way," is what set me to
thinking that perhaps you're confusing events and exceptions. The
entire WinForms object model runs on events. ADO.NET makes heavy use of
events. The Model-View-Controller design pattern that I mentioned
explicitly calls on the programmer to _prefer_ events over using simple
method calls because it vastly simplifies the application (in those
cases in which the design pattern applies).

It's exceptions that you shouldn't use for normal program flow.
Exceptions and try...catch are universally acknowledged as costly and
best avoided when it's not unreasonable to do so.

The only problem I've ever had with using events was that of
unknowingly creating circular chains of events that caused my apps to
hang, which is why I went to Model-View-Controller design, because that
design clearly lays out the responsibilities of each software component
and avoids the kind of event chaos that frequently results from
grow-your-own event architectures.

[Nick Malik]

Hi Bruce,

I was having a less than productive moment when I wrote my original reply.
While the OP was clearly referring to events, in my mind I thought he was
referring to exceptions and went off on a completely wild tangent. I should
have read the original message more carefully before responding.

Thanks for correcting my goof.

--- Nick

"Bruce Wood" <br*******@canada.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

I'm no guru, but I think that you're confusing events with exceptions.

Events don't cost considerably more than simple object calls. Raising
an event is a little bit more expensive than a simple method call
(there's a test for null, an for multicast events there is a walk down
a subscriber list). It's exceptions that introduce overhead and are
considerably more expensive than a method call.

The next statement, "Use events for error handling, never for logic
that can be detected and handled in another way," is what set me to
thinking that perhaps you're confusing events and exceptions. The
entire WinForms object model runs on events. ADO.NET makes heavy use of
events. The Model-View-Controller design pattern that I mentioned
explicitly calls on the programmer to _prefer_ events over using simple
method calls because it vastly simplifies the application (in those
cases in which the design pattern applies).

It's exceptions that you shouldn't use for normal program flow.
Exceptions and try...catch are universally acknowledged as costly and
best avoided when it's not unreasonable to do so.

The only problem I've ever had with using events was that of
unknowingly creating circular chains of events that caused my apps to
hang, which is why I went to Model-View-Controller design, because that
design clearly lays out the responsibilities of each software component
and avoids the kind of event chaos that frequently results from
grow-your-own event architectures.