Form_Load vs Constructor

[Smithers]

I have some logic that populates UI controls with values from App.config. A
couple of checkboxes get checked or unchecked; and items loaded into a
checked list box.

Two reasonable places to put this code:
1. the form's constructor (or in a method called from within the
constructor)
2. the Form_Load event procedure

What are the important considerations or tradeoffs entailed by those two
choices?

Thanks.

[Nicholas Paldino [.NET/C# MVP]]

Smithers,

If you place the code in the form's constructor, then you have to make
sure that you know that all the objects representing the child controls (the
instances of the objects, not the window handles) have been created (after
the InitializeComponent method, generally, if you are using
designer-generated code).

The Load event is called before the form is shown for the first time,
but after the form is constructed, so you know the child controls have been
created at this point.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Smithers" <[e-mail] in message
news:uO**************@TK2MSFTNGP02.phx.gbl...

>I have some logic that populates UI controls with values from App.config. A
couple of checkboxes get checked or unchecked; and items loaded into a
checked list box.

Two reasonable places to put this code:
1. the form's constructor (or in a method called from within the
constructor)
2. the Form_Load event procedure

What are the important considerations or tradeoffs entailed by those two
choices?

Thanks.

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Preference basically, if you put it in the constructor just make sure of
doing it after the call to InitializeComponents()

"Smithers" <[e-mail] in message
news:uO**************@TK2MSFTNGP02.phx.gbl...

>I have some logic that populates UI controls with values from App.config. A
couple of checkboxes get checked or unchecked; and items loaded into a
checked list box.

Two reasonable places to put this code:
1. the form's constructor (or in a method called from within the
constructor)
2. the Form_Load event procedure

What are the important considerations or tradeoffs entailed by those two
choices?

Thanks.

[Michael C]

"Smithers" <[e-mail] in message
news:uO**************@TK2MSFTNGP02.phx.gbl...

>I have some logic that populates UI controls with values from App.config. A
couple of checkboxes get checked or unchecked; and items loaded into a
checked list box.

Two reasonable places to put this code:
1. the form's constructor (or in a method called from within the
constructor)
2. the Form_Load event procedure

What are the important considerations or tradeoffs entailed by those two
choices?

Use the OnLoad override instead, events are there so *other* objects can get
notifications, an object should not generally use it's own events to get
notifications.

You can probably use the constructor as other's have said but this is what
the Load event is for so IMO it is more technically correct to put it there.

Michael

[Smithers]

RE:
<< events are there so *other* objects can get notifications, an object
should not generally use it's own events to get
notifications>>

Can you please clarify? I'm not sure what you mean by "can get
notifications" - - is there something about calling from the constructor
that would prevent it?

Thanks.


"Michael C" <no****@nospam.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

"Smithers" <[e-mail] in message
news:uO**************@TK2MSFTNGP02.phx.gbl...

>>I have some logic that populates UI controls with values from App.config.
A couple of checkboxes get checked or unchecked; and items loaded into a
checked list box.

Two reasonable places to put this code:
1. the form's constructor (or in a method called from within the
constructor)
2. the Form_Load event procedure

What are the important considerations or tradeoffs entailed by those two
choices?

Use the OnLoad override instead, events are there so *other* objects can
get notifications, an object should not generally use it's own events to
get notifications.

You can probably use the constructor as other's have said but this is what
the Load event is for so IMO it is more technically correct to put it
there.

Michael

[Michael C]

"Smithers" <[e-mail] in message
news:O0**************@TK2MSFTNGP05.phx.gbl...

RE:
<< events are there so *other* objects can get notifications, an object
should not generally use it's own events to get
notifications>>

Can you please clarify? I'm not sure what you mean by "can get
notifications"

An event is designed so other objects can get notifications from an object.
Eg, when someone clicks a button the click event is raised and the form is
"notified" of the click. A form itself does not need to use an event to get
it's own notifications, it can use the override instead.

- - is there something about calling from the constructor that would
prevent it?

This is not in reference to the constructor, I'm comparing using events to
overrides.

Michael

[Smithers]

I understand your points, I'm just not connecting them with the OP. In the
OP I'm wondering where to put some initialization code, and don't see how
the facts you state (which I agree with) relate to the question of where to
put initialization code.

RE:
<< A form itself does not need to use an event to get it's own
notifications, it can use the override instead>>
Yes, of course, but what does this have to do with the OP?

RE:

>- - is there something about calling from the constructor that would
prevent it?

This is not in reference to the constructor, I'm comparing using events to
overrides.

I see that... just not making the connection of that point with your
apparent recommendation for using Form_Load.

I suspect you know what you are trying to say... not sure it's coming across
though.

-"Smithers"
"Michael C" <no****@nospam.comwrote in message
news:eN*************@TK2MSFTNGP02.phx.gbl...

"Smithers" <[e-mail] in message
news:O0**************@TK2MSFTNGP05.phx.gbl...

>RE:
<< events are there so *other* objects can get notifications, an object
should not generally use it's own events to get
notifications>>

Can you please clarify? I'm not sure what you mean by "can get
notifications"

An event is designed so other objects can get notifications from an
object. Eg, when someone clicks a button the click event is raised and the
form is "notified" of the click. A form itself does not need to use an
event to get it's own notifications, it can use the override instead.

>- - is there something about calling from the constructor that would
prevent it?

This is not in reference to the constructor, I'm comparing using events to
overrides.

Michael

[Jack Jackson]

The OP asked about the constructor vs the Load Event.

Michael was just pointing out that if you decide to put code in the
Load Event it is better to override the form's OnLoad method rather
than hooking into the actual Load Event.

On Tue, 7 Aug 2007 17:03:04 -0700, "Smithers" <[e-mail]:

>I understand your points, I'm just not connecting them with the OP. In the
OP I'm wondering where to put some initialization code, and don't see how
the facts you state (which I agree with) relate to the question of where to
put initialization code.

RE:
<< A form itself does not need to use an event to get it's own
notifications, it can use the override instead>>
Yes, of course, but what does this have to do with the OP?

RE:

>>- - is there something about calling from the constructor that would
prevent it?

This is not in reference to the constructor, I'm comparing using events to
overrides.

I see that... just not making the connection of that point with your
apparent recommendation for using Form_Load.

I suspect you know what you are trying to say... not sure it's coming across
though.

-"Smithers"
"Michael C" <no****@nospam.comwrote in message
news:eN*************@TK2MSFTNGP02.phx.gbl...

>"Smithers" <[e-mail] in message
news:O0**************@TK2MSFTNGP05.phx.gbl...

>>RE:
<< events are there so *other* objects can get notifications, an object
should not generally use it's own events to get
notifications>>

Can you please clarify? I'm not sure what you mean by "can get
notifications"

An event is designed so other objects can get notifications from an
object. Eg, when someone clicks a button the click event is raised and the
form is "notified" of the click. A form itself does not need to use an
event to get it's own notifications, it can use the override instead.

>>- - is there something about calling from the constructor that would
prevent it?

This is not in reference to the constructor, I'm comparing using events to
overrides.

Michael

[Peter Duniho]

Smithers wrote:

I understand your points, I'm just not connecting them with the OP. In the
OP I'm wondering where to put some initialization code, and don't see how
the facts you state (which I agree with) relate to the question of where to
put initialization code.

In your original post, the two options you offered were to use the
constructor, or to use a handler for the Load event.

If I may, I believe that his point is that the second option should not
have been among the offered options. Instead, overriding the OnLoad()
method would be more appropriate, assuming you want the work to be done
during the Load event in the first place.

If the code winds up in the constructor, obviously that's a moot point.
But if it is appropriate to put it in the Load event handling, he's
saying you should do that by writing an override for OnLoad, rather than
handling the event itself.

Personally, while I agree with his point, I can't say I feel it matters
much one way or the other. If I have a situation in which I can
override the event-related method directly rather than subscribing to
the event, and there's no other design requirement necessitating the use
of the event, I will write an override rather than subscribing to the
event. But opinions may vary (and I know for a fact that they do :) ),
and I can't really say that subscribing to the event is necessarily a
bad design, even when an override is possible.

Pete

[Michael C]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

Personally, while I agree with his point, I can't say I feel it matters
much one way or the other. If I have a situation in which I can override
the event-related method directly rather than subscribing to the event,
and there's no other design requirement necessitating the use of the
event, I will write an override rather than subscribing to the event. But
opinions may vary (and I know for a fact that they do :) ), and I can't
really say that subscribing to the event is necessarily a bad design, even
when an override is possible.

I can see a couple of reasons to use the override. First, it is more
efficient than using an event. Second, the override is potentially more
reliable as it's possible to not have the event being listened to and it is
not immediately obvious (I have had this happen). I know these are fairly
minor points but if one method is slightly better yet equivelant isn't it
better to go with the one that is slightly better?

Michael

[Peter Duniho]

Michael C wrote:

I can see a couple of reasons to use the override. First, it is more
efficient than using an event.

While I agree that it's probably marginally more efficient, the override
is still virtual, so still is an indirect function call, just like the
event. I doubt there's a significantly measurable difference.

Second, the override is potentially more
reliable as it's possible to not have the event being listened to and it is
not immediately obvious (I have had this happen).

Assuming your own override correctly calls the base implementation, it's
only possible for an event to not be raised if the class has been
overridden and someone else's override of OnLoad doesn't call the base
implementation. Which, as it turns out, is the same scenario in which
your own override won't get called either.

In other words, the event and the override both have the potential for
not being called, and it's unclear to me that one is more likely than
the other, since the scenarios are the same.

I know these are fairly
minor points but if one method is slightly better yet equivelant isn't it
better to go with the one that is slightly better?

Like I said, I personally prefer using the override. It does seem more
correct to me. But I wouldn't want to waste time arguing about it with
someone who was set on using the event instead. I'm not convinced
there's a big enough difference to make it worth worrying about.

IMHO, one significant thing that the override gets you is the ability to
effectively cancel the event, even if it's not a cancellable event. But
this need is unusual, and doesn't apply in the more general case (even
though it does obviously apply in that specific scenario). In the
general case, I really don't see a significant difference between the
two except stylistically.

Pete

[Peter Duniho]

Michael C wrote:

[...]

>Assuming your own override correctly calls the base implementation, it's
only possible for an event to not be raised if the class has been
overridden and someone else's override of OnLoad doesn't call the base
implementation. Which, as it turns out, is the same scenario in which
your own override won't get called either.

This is true although less likely. Usually if an override is used the event
won't be.

That's not true, especially if you follow the stipulation that the event
is for use only by code outside the class. If one assumes that the
event is useful at all (and if it's not, why does it exist?), then by
your stipulation, there _is_ still going to be code that uses it, even
if the OnLoad() method is overridden.

The two are not mutually exclusive, and that is _especially_ true under
the conditions you and I both agree are more desirable (that is, the
event is used only by code outside of the class).

>In other words, the event and the override both have the potential for not
being called, and it's unclear to me that one is more likely than the
other, since the scenarios are the same.

While they are possibly both equally likely it is more likely the event will
be a problem. The event is a problem in 100% of cases where the override
might be a small percentage.

I don't understand that statement. The only typical scenario I can
think of where a properly subscribed event wouldn't get raised is when
the OnLoad() method was overridden, but improperly so that the base
implementation wasn't called, and thus the event wasn't raised.

An improper override is the cause in both the problematic override case
and the problematic event case. Since both have the same cause, both
consequences should have the same relative occurrence.

So, I don't understand what you mean by "the event is a problem in 100%
of cases where the override might be a small percentage". 100% of which
cases? A small percentage of which cases? Why are the two rates of
incidence not the same, given that the underlying cause _is_ the same?
Shouldn't the rate of incidence be equal to the rate of incidence for
the underlying cause? And then wouldn't the rate of incidence for both
types of problems be equal, given that they are both equal to the same
number?

>Like I said, I personally prefer using the override. It does seem more
correct to me. But I wouldn't want to waste time arguing about it with
someone who was set on using the event instead. I'm not convinced there's
a big enough difference to make it worth worrying about.

There is a reasonable overhead involved with events.

For example? What overhead specifically are you talking about? In what
way is using an event significantly more expensive that using an override?

Pete

[Michael C]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

>This is true although less likely. Usually if an override is used the
event won't be.

That's not true, especially if you follow the stipulation that the event
is for use only by code outside the class. If one assumes that the event
is useful at all (and if it's not, why does it exist?), then by your
stipulation, there _is_ still going to be code that uses it, even if the
OnLoad() method is overridden.

I think it is true. If you override OnLoad then it is unlikely that you will
also use Form_Load. Certainly it is less likely.

I don't understand that statement. The only typical scenario I can think
of where a properly subscribed event

You're assuming a properly subscribed event. I'm comparing someone
forgetting to call OnLoad to someone who has failed to subscribe to the
event correctly. In the case of failing to call OnLoad it is possible (and
likely) that code will continue to work because the event might not be used.
In the case of the event not being subscribed to correctly it is always a
problem.

For example? What overhead specifically are you talking about? In what
way is using an event significantly more expensive that using an override?

I don't know the full details but you have a delegate involved which is a
seperate object. It needs to enumerate the list of subscribers and call each
one. There are references between these different objects that need to be
cleaned up.

>
Pete

[Peter Duniho]

Michael C wrote:

I think it is true. If you override OnLoad then it is unlikely that you will
also use Form_Load. Certainly it is less likely.

If one should always override OnLoad, and when you override OnLoad you
will never use the event, then why does the event exist at all?

>I don't understand that statement. The only typical scenario I can think
of where a properly subscribed event

You're assuming a properly subscribed event.

And why not? If the original implementation of the class is buggy to
start with, it doesn't really matter how it was implemented at all.

I'm comparing someone
forgetting to call OnLoad to someone who has failed to subscribe to the
event correctly. In the case of failing to call OnLoad it is possible (and
likely) that code will continue to work because the event might not be used.
In the case of the event not being subscribed to correctly it is always a
problem.

Again, that's just not true. Failing to call OnLoad is every bit as
much a problem as failing to raise the event, and for the same reasons.
If you have overridden OnLoad, presumably you did so for a good
reason. If your override is then not called, that's a problem.

Calling OnLoad is not just for the purpose of raising the event. It
surprises me that you wouldn't consider that fact, since you are the one
saying that you should _always_ override OnLoad to implement something
like this.

>For example? What overhead specifically are you talking about? In what
way is using an event significantly more expensive that using an override?

I don't know the full details but you have a delegate involved which is a
seperate object. It needs to enumerate the list of subscribers and call each
one. There are references between these different objects that need to be
cleaned up.

Well, when you have some actual information that can justify your claim
that there's significantly more overhead using the event than an
override, it would make sense to bring that up as a point. Until then,
it's not a valid point.

Personally, I doubt there is any significant difference.

Pete

[Michael C]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

Again, that's just not true. Failing to call OnLoad is every bit as much
a problem as failing to raise the event,

Peter, please slow down for a moment and try to read my post. I'm fairly
convinced that you are scanning over what I've written too quickly and
basically getting the completely wrong idea and going off on a tangent.

I'm not talking about failing to raise an event, I'm talking about failing
to *subscribe* to the event, ie the line

this.Load += new whatever

is missing. If you still have the Form_Load routine in your code then it
appears to the programmer that everything is fine. *Every* time this line is
missing it will be a problem. On the other hand if you fail to call OnLoad
in the override this will not be an issue in most cases. This is why I say
the OnLoad is potentially more reliable because if it's there in code then
it is getting called.

Well, when you have some actual information that can justify your claim
that there's significantly more overhead using the event than an override,
it would make sense to bring that up as a point. Until then, it's not a
valid point.

Check google, it is fairly well known that events have a larger overhead.

Personally, I doubt there is any significant difference.

Do as you wish :-)

Michael

[Jack Jackson]

On Sun, 12 Aug 2007 21:31:02 -0700, Peter Duniho
<Np*********@NnOwSlPiAnMk.comwrote:

>Michael C wrote:

>I think it is true. If you override OnLoad then it is unlikely that you will
also use Form_Load. Certainly it is less likely.

If one should always override OnLoad, and when you override OnLoad you
will never use the event, then why does the event exist at all?

Events are there so other objects can be notified of things happening.
The OnXXX methods are there so subclasses can be notified of things
happening more efficiently than by using an event.

[Peter Duniho]

Michael C wrote:

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

>Again, that's just not true. Failing to call OnLoad is every bit as much
a problem as failing to raise the event,

Peter, please slow down for a moment and try to read my post.

Right back at you.

I was writing about the two negative outcomes to failing to call the
base class: one is that the OnLoad method itself does not get called;
the other is that failing to call the base OnLoad also results in a
failure for the event to be raised.

Somehow, you seem to have missed this point.

I'm fairly
convinced that you are scanning over what I've written too quickly and
basically getting the completely wrong idea and going off on a tangent.

Yes, I can see that you are convinced. If you would spend a little more
time reading my post rather than just assuming I'm blowing you off, you
might not be so convinced.

I'm not talking about failing to raise an event, I'm talking about failing
to *subscribe* to the event, ie the line

this.Load += new whatever

I know.

is missing. If you still have the Form_Load routine in your code then it
appears to the programmer that everything is fine. *Every* time this line is
missing it will be a problem. On the other hand if you fail to call OnLoad
in the override this will not be an issue in most cases. This is why I say
the OnLoad is potentially more reliable because if it's there in code then
it is getting called.

And my point is that there are really two parts to this question: is the
original implementation correct? And is a derived implementation correct?

Answering the first part is easy: either it works or it doesn't. If you
properly subscribe to the event, you're fine. Since you made the
original design decision to subscribe rather than override, presumably
it is trivial to subscribe correctly.

Answer the second part is harder, because you are not in control of the
derived implementation at the point in time that you write the base
implementation. But as far as that goes, the derived implementation can
mess up either the event-based implementation or the override based
implementation, and it will mess them both up in the same way: it will
fail to call the base class's method.

This originally came up in the context of you claiming that even though
the programming errors involved are "possibly both equally likely", that
it was the case that "The event is a problem in 100% of cases where the
override might be a small percentage".

You have yet to post something that explains exactly what percentages
you're talking about, never mind explains the math involved.

>Well, when you have some actual information that can justify your claim
that there's significantly more overhead using the event than an override,
it would make sense to bring that up as a point. Until then, it's not a
valid point.

Check google, it is fairly well known that events have a larger overhead.

I checked Google, and it had nothing to say on the topic that supports
your claim.

If you want to make a claim, back it up. If you can't back it up, then
you have no business making the claim. And no, saying "look it up" is
not backing up the claim. If you yourself cannot readily provide the
references to justify the claim, then you yourself do not have the
first-hand knowledge required to legitimately make the claim.

Pete

[Peter Duniho]

Jack Jackson wrote:

>>I think it is true. If you override OnLoad then it is unlikely that you will
also use Form_Load. Certainly it is less likely.

If one should always override OnLoad, and when you override OnLoad you
will never use the event, then why does the event exist at all?

Events are there so other objects can be notified of things happening.

According to Michael, no other objects will subscribe to the event.
Thus my question.

The OnXXX methods are there so subclasses can be notified of things
happening more efficiently than by using an event.

I doubt that efficiency is even a secondary reason for the methods
existing. Certainly the primary reason has more to do with the overall
design of the .NET classes, than any efficiency concern. As has been
mentioned elsewhere (in this thread, even), providing a virtual method
for derived classes to override provides enhanced control over the
sequencing of raising of events, as well as whether events are raised at
all.

The overridable methods are more about the capabilities of the
architecture than of some efficiency issue.

Pete

[Michael C]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

>Peter, please slow down for a moment and try to read my post.

Right back at you.

I was writing about the two negative outcomes to failing to call the base
class: one is that the OnLoad method itself does not get called; the other
is that failing to call the base OnLoad also results in a failure for the
event to be raised.

Somehow, you seem to have missed this point.

I have not missed this point at all. The OnLoad in the base class does
nothing but raise the event. Certainly I have missed calling OnLoad many
many times and had no side effects.

Yes, I can see that you are convinced. If you would spend a little more
time reading my post rather than just assuming I'm blowing you off, you
might not be so convinced.

So far you have expressed confusion at most of what I have posted.

This originally came up in the context of you claiming that even though
the programming errors involved are "possibly both equally likely", that
it was the case that "The event is a problem in 100% of cases where the
override might be a small percentage".

You have yet to post something that explains exactly what percentages
you're talking about, never mind explains the math involved.

It's fairly simple. Missing the this.Load += whatever is *always* a problem,
ie 100%. Failing to call OnLoad is not going to always going to be a
problem, ie a number less the 100%.

I checked Google, and it had nothing to say on the topic that supports
your claim.

Sounds like the classic "I haven't listened to a single complaint" :-)
Google would most definately have information on this.

If you want to make a claim, back it up. If you can't back it up, then
you have no business making the claim. And no, saying "look it up" is not
backing up the claim. If you yourself cannot readily provide the
references to justify the claim, then you yourself do not have the
first-hand knowledge required to legitimately make the claim.

My claim is fairly well known and accepted. If you wish to challenge the
fact that the world is not flat then you need to provide information. So far
I have provided the fact that at least 1 additional object (the delegate) is
required which contains a collection of listeners. This indicates that there
is at least some additional overhead, it's up to you to disprove this.

Michael

[Michael C]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

According to Michael, no other objects will subscribe to the event. Thus
my question.

You claim you're reading my posts but still don't get what I'm saying. I'm
not saying no other object will ever subscribe to the event. I'll repeat
again - what I did say was it was LESS LIKELY to the event would be used in
this case given the override was being used.

>The OnXXX methods are there so subclasses can be notified of things
happening more efficiently than by using an event.

I doubt that efficiency is even a secondary reason for the methods
existing. Certainly the primary reason has more to do with the overall
design of the .NET classes, than any efficiency concern. As has been
mentioned elsewhere (in this thread, even), providing a virtual method for
derived classes to override provides enhanced control over the sequencing
of raising of events, as well as whether events are raised at all.

The overridable methods are more about the capabilities of the
architecture than of some efficiency issue.

That's probably true, although given they are more efficient they may as
well be used.

Michael

[Peter Duniho]

Michael C wrote:

[...]
I have provided the fact that at least 1 additional object (the delegate) is
required which contains a collection of listeners. This indicates that there
is at least some additional overhead, it's up to you to disprove this.

Ignoring for a moment that your analysis doesn't say anything about the
actual cost of executing the event or method, I will simply say this: I
have disproved this. See the other article I just posted.

Pete

[Peter Duniho]

Michael C wrote:

>I was writing about the two negative outcomes to failing to call the base
class: one is that the OnLoad method itself does not get called; the other
is that failing to call the base OnLoad also results in a failure for the
event to be raised.

Somehow, you seem to have missed this point.

I have not missed this point at all.

Yes, you have. You continue to.

The OnLoad in the base class does
nothing but raise the event.

The "base class" in my post is YOUR class. Presumably if you took the
time to write an override method for OnLoad, it does more than just
raise the event.

>Yes, I can see that you are convinced. If you would spend a little more
time reading my post rather than just assuming I'm blowing you off, you
might not be so convinced.

So far you have expressed confusion at most of what I have posted.

If by "confusion" you mean I have posted comments indicating that what
you've posted doesn't make any sense, yes. I'd have to agree with your
statement here.

>You have yet to post something that explains exactly what percentages
you're talking about, never mind explains the math involved.

It's fairly simple. Missing the this.Load += whatever is *always* a problem,
ie 100%. Failing to call OnLoad is not going to always going to be a
problem, ie a number less the 100%.

Failing to call OnLoad in a class derived from your implementation that
includes an OnLoad override IS _always_ going to be a problem. 100% of
the time.

If you want to restrict the scenario to only your specific
implementation, then I'd say you are no more or less likely to forget to
subscribe your event than you are to forget to write the OnLoad
override. The fact is, both errors are basically non-existent. Your
"math" is contrived.

>I checked Google, and it had nothing to say on the topic that supports
your claim.

Sounds like the classic "I haven't listened to a single complaint" :-)
Google would most definately have information on this.

Feel free to post a Google search that would easily turn up the
information you claim is easily found there. Be sure to point out the
URLs that the search returns that actually provide the information you
claim they provide.

I am happy to acknowledge that I've somehow missed something. But so
far, all you've done is express an inability to actually point to
something I've missed. That's a pretty lame debating tactic, and one
that's sure to fail you every time.

If I'm wrong, show me. If you can't show me, well..."put up or shut up"
seems to apply here.

Pete

[Michael C]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

And, by the way, since something as easily tested as this is such a dumb
thing to even get stuck on, I wrote a small console application to test
the difference (code copied below).

This test is hardly a complete at all. Do you think the OnLoad method of
form will simply raise the event without even checking whether it is null or
not? Let alone all the other potential code it could have?

Also, efficiency is not just the speed at which the event is called, in fact
this is likely to be the least important factor in the majority of cases.
The amount of objects and references it creates is going to be more
important in 99%+ of cases.

Michael

[Michael C]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

The "base class" in my post is YOUR class. Presumably if you took the
time to write an override method for OnLoad, it does more than just raise
the event.

In many cases it does not.

If by "confusion" you mean I have posted comments indicating that what
you've posted doesn't make any sense, yes. I'd have to agree with your
statement here.

No, you have expressed genuine confusion. I have had to explain a very
simple point over and over and I still don't think you get it.

Failing to call OnLoad in a class derived from your implementation that
includes an OnLoad override IS _always_ going to be a problem. 100% of
the time.

No way. There are most definately cases where the OnLoad in the base class
will simply raise an event that is not used. Hence the number MUST be less
than 100%.

If you want to restrict the scenario to only your specific implementation,
then I'd say you are no more or less likely to forget to subscribe your
event than you are to forget to write the OnLoad override. The fact is,
both errors are basically non-existent. Your "math" is contrived.

Largely this will apply to forms. It applies to controls or other objects
much less often.

Feel free to post a Google search that would easily turn up the
information you claim is easily found there. Be sure to point out the
URLs that the search returns that actually provide the information you
claim they provide.

No. This is something I have read many times and is fairly widely accepted.
I'm not going to waste my time proving the sky is blue.

I am happy to acknowledge that I've somehow missed something. But so far,
all you've done is express an inability to actually point to something
I've missed. That's a pretty lame debating tactic, and one that's sure to
fail you every time.

If I'm wrong, show me. If you can't show me, well..."put up or shut up"
seems to apply here.

Whatever. Clearly you spent a reasonable amount of time benchmarking events
to prove nothing. I'm just not as invested in this thread as you.

Michael

[Peter Duniho]

Michael C wrote:

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

>The "base class" in my post is YOUR class. Presumably if you took the
time to write an override method for OnLoad, it does more than just raise
the event.

In many cases it does not.

Please post a real-world example of an implementation of a class that
overrides OnLoad and yet does nothing but raise the event. By
"real-world", I mean an implementation that clearly needs to override
OnLoad, and would be seen in an actual program.

[...]

>If I'm wrong, show me. If you can't show me, well..."put up or shut up"
seems to apply here.

Whatever. Clearly you spent a reasonable amount of time benchmarking events
to prove nothing. I'm just not as invested in this thread as you.

Yes, I can understand how when you cannot support your claims, being
"not as invested" would be a desirable position to be in.

I accept your decision to "shut up" rather than "put up". Thank you.

Pete

[Peter Duniho]

Michael C wrote:

This test is hardly a complete at all. Do you think the OnLoad method of
form will simply raise the event without even checking whether it is null or
not? Let alone all the other potential code it could have?

The question here is whether calling an event is more costly than
calling a virtual method. My code tests that.

Please feel free to post an alternative benchmark that demonstrates your
point.

Also, efficiency is not just the speed at which the event is called, in fact
this is likely to be the least important factor in the majority of cases.
The amount of objects and references it creates is going to be more
important in 99%+ of cases.

I agree. And since those things are identical regardless of whether you
use a virtual method or an event, _whatever_ performance difference
exists between using a virtual method or an event is EVEN LESS. Which
is, by the way, what I've been saying all along.

You are the one claiming that there is a significant difference between
calling a virtual method and using an event. All you're doing now is
arguing against your own claim.

Pete

[Michael C]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

Please post a real-world example of an implementation of a class that
overrides OnLoad and yet does nothing but raise the event. By
"real-world", I mean an implementation that clearly needs to override
OnLoad, and would be seen in an actual program.

I'm talking about the *base* class.

Yes, I can understand how when you cannot support your claims, being "not
as invested" would be a desirable position to be in.

I accept your decision to "shut up" rather than "put up". Thank you.

Again mate, if you want to question the generally accepted norm then go
ahead and provide some evidence.

Michael

[Michael C]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

The question here is whether calling an event is more costly than calling
a virtual method. My code tests that.

No, the question is whether attaching to an event, detaching etc etc and
then calling it is more expensive. Most of us look at the entire picture.

Please feel free to post an alternative benchmark that demonstrates your
point.

Could not be bothered but I have no doubt the event would be less efficent
overall.

I agree. And since those things are identical regardless of whether you
use a virtual method or an event, _whatever_ performance difference exists
between using a virtual method or an event is EVEN LESS. Which is, by the
way, what I've been saying all along.

You are the one claiming that there is a significant difference between
calling a virtual method and using an event. All you're doing now is
arguing against your own claim.

Actually I never said there was a significant difference, in fact I claimed
there was a small difference. However given there is a small difference it's
better to use the override as it is more efficient.

Michael

[Peter Duniho]

Michael C wrote:

>Please post a real-world example of an implementation of a class that
overrides OnLoad and yet does nothing but raise the event. By
"real-world", I mean an implementation that clearly needs to override
OnLoad, and would be seen in an actual program.

I'm talking about the *base* class.

I am too.

The difference being that I am talking about the base class, regardless
of whether it is one that derives from an existing .NET class or not,
while you have chosen to arbitrarily restrict your consideration to a
specific base class (I assume the Control class, since you are so
focused on the behavior of that class's implementation of OnLoad, but
you haven't been explicit so I can't be sure).

Make no mistake: your restriction _is_ arbitrary, and focusing only on
one specific base class completely misses the real issues regarding how
overriding OnLoad could fail.

Again mate, if you want to question the generally accepted norm then go
ahead and provide some evidence.

You've yet to support your assertion that your position _is_ the
"generally accepted norm". So frankly, while I certainly am in the
habit of questioning "the generally accepted norm" when that "norm"
makes no sense, there's no indication at all that I'm doing so in this case.

Pete

[Michael C]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

I am too.

The difference being that I am talking about the base class, regardless of
whether it is one that derives from an existing .NET class or not, while
you have chosen to arbitrarily restrict your consideration to a specific
base class (I assume the Control class, since you are so focused on the
behavior of that class's implementation of OnLoad, but you haven't been
explicit so I can't be sure).

Make no mistake: your restriction _is_ arbitrary, and focusing only on one
specific base class completely misses the real issues regarding how
overriding OnLoad could fail.

Hang on a sec there. In any class where I have an override that corresponds
to an event it's unlikely the code will do anything except raise the event.
Remember we are talking about an OnWhatever function and a Whatever event.
It's *extremely* likely the OnWhatever function will do nothing except raise
the event.

Beside which the Form is going to be what this applies to in 99% of cases.

You've yet to support your assertion that your position _is_ the
"generally accepted norm". So frankly, while I certainly am in the habit
of questioning "the generally accepted norm" when that "norm" makes no
sense, there's no indication at all that I'm doing so in this case.

I really don't care.

Michael

[Smithers]

<snip>

>You've yet to support your assertion that your position _is_ the
"generally accepted norm". So frankly, while I certainly am in the habit
of questioning "the generally accepted norm" when that "norm" makes no
sense, there's no indication at all that I'm doing so in this case.

I really don't care.

The intent behind my OP [of this thread] is to learn best practices and
such. So I'm very much interested in learning about accepted norms that may
be floating around - of which I may be unaware. If you have "checked out" of
caring about this thread and don't want to post specific links, can you at
least reply with some key words or phrases that I can google to discover
this norm of which you write?

Thanks

[Peter Duniho]

Michael C wrote:

As I said, I cannot be bothered. I really don't care enough about your
misunderstanding to give you the educating you need.

You fail to comprehend that this is not just about "my
misunderstanding". It is also about "your misunderstanding". So far,
the only thing objective posted to this thread has been by me, showing
your own misunderstanding.

This isn't about "the educating I need". This is about getting the
facts right. If you can't be bothered, what you can't be bothered with
is getting the facts right.

Your own arrogance, insisting that you are right without be able to be
bothered to investigate whether that's true or not, is getting in your
own way of learning something.

[...]
Your tests were clearly shown to be flawed.

By whom? I must have missed where that happened. Please show me where
my tests "were clearly shown to be flawed". All you've posted is
conjecture. You certainly have suggested my test was flawed, but you've
done absolutely nothing to _show_ they are flawed, never mind do so
"clearly".

While the efficiency might be
minor a minor difference is enough for me. In cases like this were it's
pretty much the same either way a small difference tips the scales.

Nope. There are significant differences in the higher-level aspects of
using an override versus an event. The design issues clearly win out
over any insignificant efficiency issue.

Pete

[Michael C]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

You fail to comprehend that this is not just about "my misunderstanding".
It is also about "your misunderstanding". So far, the only thing
objective posted to this thread has been by me, showing your own
misunderstanding.

Funny.

This isn't about "the educating I need". This is about getting the facts
right. If you can't be bothered, what you can't be bothered with is
getting the facts right.

Your own arrogance, insisting that you are right without be able to be
bothered to investigate whether that's true or not, is getting in your own
way of learning something.

Events are well known to be less efficient, I have read this *many* times
over the years and have accepted it long ago. If you want to disprove it
then go ahead.

By whom?

Me silly.

I must have missed where that happened.

Not the first time, you'll be telling me again how you've missed nothing.

Please show me where my tests "were clearly shown to be flawed". All
you've posted is conjecture. You certainly have suggested my test was
flawed, but you've done absolutely nothing to _show_ they are flawed,
never mind do so "clearly".

I have shown they are missing the attachment of the event. All you are
testing is the speed of calling an event without even checking if exists. If
you don't think that's flawed then what can I say. I suspect you've tried
these things and found the event to be less efficient so haven't posted the
results.

Nope. There are significant differences in the higher-level aspects of
using an override versus an event. The design issues clearly win out over
any insignificant efficiency issue.

Maybe in some cases, but 99% of the time it makes no difference except the
efficiency.

Michael

[Michael C]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...

By whom? I must have missed where that happened. Please show me where my
tests "were clearly shown to be flawed". All you've posted is conjecture.
You certainly have suggested my test was flawed, but you've done
absolutely nothing to _show_ they are flawed, never mind do so "clearly".

I'm done with this thread pete. I really can't be bothered arguing with you
over something that is generally accepted. I'm certainly not going to do the
work for you so you can prove afterall that events are less efficient. If
you want to question the norm then *you* need to do the work.

Michael

[Paul Werkowitz]

Am Thu, 2 Aug 2007 12:55:39 -0400 schrieb Nicholas Paldino [.NET/C# MVP]:

The Load event is called before the form is shown for the first time,
but after the form is constructed, so you know the child controls have been
created at this point.

That's what I thought, too. But place a WebBrowserControl on you form, and
you will see, that OnLoad is called from *within* InitializeComponent....
(when the WebBrowser is added to the controls collection, to be precise).
This caused weird behavior in our program because we too assumed that
OnLoad will be called with all controls properly initialized .. Not So!

Pls note that the docs only state that OnLoad is called BEFORE the form is
shown. They do not say that OnLoad is called after the controls are
initialized.

I moved all code from OnLoad into the ctor and all is well again.

Greetz
Paule