BUG?: VB.Net - Inherited form. Known Issue?

[Lorne Smith]

Hi,

First, sorry for the crosspost, but it seemed appropriate... :)

I've come accross what I consider to be a bug, but I don't know if it's
already known or not. (VS .Net 2003 Pro - VB.Net)

Whilst playing with inherited forms, I created a simple base form containing
a single button. I set this buttons' Click event to be public overridable
and put "me.Close" in the code.

I then built the project and added a new inherited form using this base
form. All well so far. Now, I then went to the code view of the inherited
form, chose the Overridable Button_Click event which gave me the following:

\\\
Public Overrides Sub Button1_Click(ByVal sender As Object, ByVal e As
System.EventArgs)

End Sub
///

All well and good. Code inserted in here works fine. However, for some
reason I deleted this sub from the code and went to the designer. Then I
double clicked the button to take me back to the code window and it
recreated the sub as below.

\\\
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

End Sub
///

Obviously, this isn't going to work as the base method is public
overridable... I changed the sub declaration to Public Overrides and the
error went away, but when I put code in the sub, it was executed twice when
I ran the form. Now I realised this is because both the base form and the
inherited form are handling the event, but my question is, WHY did the
double click of the control create the event in such as unusable manner? It
seems a little silly to create the event as Private, when the base method is
Public Overridable!!

Is this known about already?

Regards

Lorne

[Armin Zingler]

"Lorne Smith" <[e-mail]> schrieb

Obviously, this isn't going to work as the base method is public
overridable... I changed the sub declaration to Public Overrides and
the error went away, but when I put code in the sub, it was executed
twice when I ran the form. Now I realised this is because both the
base form and the inherited form are handling the event, but my
question is, WHY did the double click of the control create the event
in such as unusable manner?

It seems a little silly to create the
event as Private, when the base method is Public Overridable!!

Is this known about already?

The designer creates the default procedure for events. Event procedures are
usually not Public Overridable. IMO, you should not change the signature in
the base class. If you want an overridable sub handling the Click, add an
Overridable OnButtonClick procedure called in the event handler of the base
class. In the derived class, override OnButtonClick.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Lorne Smith]

"Armin Zingler" <az*******@freenet.de> wrote in message
news:uA**************@TK2MSFTNGP12.phx.gbl...

"Lorne Smith" <[e-mail]> schrieb

Obviously, this isn't going to work as the base method is public
overridable... I changed the sub declaration to Public Overrides and
the error went away, but when I put code in the sub, it was executed
twice when I ran the form. Now I realised this is because both the
base form and the inherited form are handling the event, but my
question is, WHY did the double click of the control create the event
in such as unusable manner?

It seems a little silly to create the
event as Private, when the base method is Public Overridable!!

Is this known about already?
The designer creates the default procedure for events. Event procedures

are usually not Public Overridable. IMO, you should not change the signature in the base class. If you want an overridable sub handling the Click, add an
Overridable OnButtonClick procedure called in the event handler of the base class. In the derived class, override OnButtonClick.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

OK, I get that, but I had been following an online seminar on MSs site, and
they showed this method of doing it (overriding the default procedure)...
It seems even more daft if the method they show in instructional videos is
not the advisable method (though I'm not too surprised by that!!)...

Lorne

[Armin Zingler]

"Lorne Smith" <[e-mail]> schrieb

OK, I get that, but I had been following an online seminar on MSs
site, and they showed this method of doing it (overriding the default
procedure)... It seems even more daft if the method they show in
instructional videos is not the advisable method (though I'm not too
surprised by that!!)...

It's only me saying that it is not advisable. ;-)
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Lorne Smith]

"Armin Zingler" <az*******@freenet.de> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

"Lorne Smith" <[e-mail]> schrieb

OK, I get that, but I had been following an online seminar on MSs
site, and they showed this method of doing it (overriding the default
procedure)... It seems even more daft if the method they show in
instructional videos is not the advisable method (though I'm not too
surprised by that!!)...

It's only me saying that it is not advisable. ;-)
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

Ah... So... Is it a bug then? Or just an idiosyncracy of how inherited
forms work? It's easy enough to work around, just that I'm in the habit of
clicking the control to generate the event, you know?

Lorne

[Herfried K. Wagner [MVP]]

* "Lorne Smith" <[e-mail]> scripsit:

I've come accross what I consider to be a bug, but I don't know if it's
already known or not. (VS .Net 2003 Pro - VB.Net)

Whilst playing with inherited forms, I created a simple base form containing
a single button. I set this buttons' Click event to be public overridable
and put "me.Close" in the code.

I then built the project and added a new inherited form using this base
form. All well so far. Now, I then went to the code view of the inherited
form, chose the Overridable Button_Click event which gave me the following:

\\\
Public Overrides Sub Button1_Click(ByVal sender As Object, ByVal e As
System.EventArgs)

End Sub
///
Why did you mark the handler as 'Overridable'?
All well and good. Code inserted in here works fine. However, for some
reason I deleted this sub from the code and went to the designer. Then I
double clicked the button to take me back to the code window and it
recreated the sub as below.

\\\
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

End Sub
///

Obviously, this isn't going to work as the base method is public
overridable...
Seems to be a limitation of the designer. Nevertheless, I don't
understand why you declare the handler as 'Overridable' in the base
form. Usually, you can override methods called 'On*' in the base form.
I changed the sub declaration to Public Overrides and the
error went away, but when I put code in the sub, it was executed twice when
I ran the form.

Are you sure? Maybe you want to remove the handler defined in the base
form (notice that it's an event handler)!

\\\
RemoveHandler Me.Button1.Click, AddressOf MyBase.Button1_Click
///

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Johan Jooris]

Hi,

I was also experimenting with visual inheritance of forms and I encountered
the following problem, which keeps me from using visual inheritance:
I designed a simple base form, with eg a buttoncontrol anchored at the
right - bottom corner.
I then changed the modifier of the button from friend to protected friend.

I added a new inherited forms, which inherits from this base form, adn I
change the size of the form.
When closing the form and reopening it in the designer, the button is placed
somewhere on the screen, but not on the place where it should, ie x pixels
from the right, y pixels from the button.

What am I doing wrong, or is it a bug in the vs

"Lorne Smith" <[e-mail]> schreef in bericht
news:ez*************@tk2msftngp13.phx.gbl...

Hi,

First, sorry for the crosspost, but it seemed appropriate... :)

I've come accross what I consider to be a bug, but I don't know if it's
already known or not. (VS .Net 2003 Pro - VB.Net)

Whilst playing with inherited forms, I created a simple base form containing a single button. I set this buttons' Click event to be public overridable
and put "me.Close" in the code.

I then built the project and added a new inherited form using this base
form. All well so far. Now, I then went to the code view of the inherited form, chose the Overridable Button_Click event which gave me the following:
\\\
Public Overrides Sub Button1_Click(ByVal sender As Object, ByVal e As
System.EventArgs)

End Sub
///

All well and good. Code inserted in here works fine. However, for some
reason I deleted this sub from the code and went to the designer. Then I
double clicked the button to take me back to the code window and it
recreated the sub as below.

\\\
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

End Sub
///

Obviously, this isn't going to work as the base method is public
overridable... I changed the sub declaration to Public Overrides and the
error went away, but when I put code in the sub, it was executed twice when I ran the form. Now I realised this is because both the base form and the
inherited form are handling the event, but my question is, WHY did the
double click of the control create the event in such as unusable manner? It seems a little silly to create the event as Private, when the base method is Public Overridable!!

Is this known about already?

Regards

Lorne

[Armin Zingler]

"Lorne Smith" <[e-mail]> schrieb

OK, I get that, but I had been following an online seminar on
MSs site, and they showed this method of doing it (overriding the
default procedure)... It seems even more daft if the method they
show in instructional videos is not the advisable method (though
I'm not too surprised by that!!)...
It's only me saying that it is not advisable. ;-)

Ah... So... Is it a bug then?

No, by "not advisable" you (and I) referred to changing the signature in the
base class, not to the designer generated code in the derived form. So, you
can do it or you don't, but it's not a bug.
Or just an idiosyncracy of how
inherited forms work? It's easy enough to work around, just that I'm
in the habit of clicking the control to generate the event, you
know?

Maybe I got you wrong, but I can not double-click on the button in the
derived form. Well, I can, but nothing happens because it's an inherited
button.

Referring to your question:
"WHY did the
double click of the control create the event in such as unusable manner? It
seems a little silly to create the event as Private, when the base method is
Public Overridable!!"

In theory you can have several procedures in the base class, all handling
the button's click event. Some of the procedures might be private, some
public, some are overridable, some not. Do you expect the procedure,
generated in the derived form when you double-click the button (which does
not work here with me (VB 2002?)), to be overridable, public or private? It
would be ambiguous because there are procedures with different modifiers in
the base class handling the same event.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Lorne Smith]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

* "Lorne Smith" <[e-mail]> scripsit:

I've come accross what I consider to be a bug, but I don't know if it's
already known or not. (VS .Net 2003 Pro - VB.Net)

Whilst playing with inherited forms, I created a simple base form containing a single button. I set this buttons' Click event to be public overridable and put "me.Close" in the code.

I then built the project and added a new inherited form using this base
form. All well so far. Now, I then went to the code view of the inherited form, chose the Overridable Button_Click event which gave me the following:
\\\
Public Overrides Sub Button1_Click(ByVal sender As Object, ByVal e As
System.EventArgs)

End Sub
///

Why did you mark the handler as 'Overridable'?

All well and good. Code inserted in here works fine. However, for some
reason I deleted this sub from the code and went to the designer. Then I double clicked the button to take me back to the code window and it
recreated the sub as below.

\\\
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

End Sub
///

Obviously, this isn't going to work as the base method is public
overridable...

Seems to be a limitation of the designer. Nevertheless, I don't
understand why you declare the handler as 'Overridable' in the base
form. Usually, you can override methods called 'On*' in the base form.

I changed the sub declaration to Public Overrides and the
error went away, but when I put code in the sub, it was executed twice when I ran the form.

Are you sure? Maybe you want to remove the handler defined in the base
form (notice that it's an event handler)!

\\\
RemoveHandler Me.Button1.Click, AddressOf MyBase.Button1_Click
///

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Hi Herfried,

I was following the "Developing Windows Forms applications with Visual
Basic.NET" seminar found here:
http://msdn.ms.demoservers.com/skins/msdn-us/login.htm

In here, they did precisely what I did, changed the default event of the
button click to public overridable, then overrode it in the inherited form.
I was merely following the examples as, though I'm an experienced VB6
programmer, I've only just got around to learning .NET so was deliberately
starting at the beginning, especially as I've never used an inherited form
before (used to templates...)

I just find it rather silly that double clicking the button on the inherited
form (in VS .NET 2003 Pro), creates a default event code segment which
cannot be executed until you change it to Public Overrides and remove the
handler code at the end of the sub declaration.

Lorne

[CJ Taylor]

I think it is also very important to remember that when building a designer
as robust as Visual Studio, that you may not be able to please everyone.

That or its a conspiracy by microsoft to make us all better programmers...
by learning from example...

"Lorne Smith" <[e-mail]> wrote in message
news:uR**************@TK2MSFTNGP11.phx.gbl...

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

* "Lorne Smith" <[e-mail]> scripsit:

I've come accross what I consider to be a bug, but I don't know if it's already known or not. (VS .Net 2003 Pro - VB.Net)

Whilst playing with inherited forms, I created a simple base form containing a single button. I set this buttons' Click event to be public overridable and put "me.Close" in the code.

I then built the project and added a new inherited form using this base form. All well so far. Now, I then went to the code view of the inherited form, chose the Overridable Button_Click event which gave me the following:
\\\
Public Overrides Sub Button1_Click(ByVal sender As Object, ByVal e As
System.EventArgs)

End Sub
///
Why did you mark the handler as 'Overridable'?

All well and good. Code inserted in here works fine. However, for some reason I deleted this sub from the code and went to the designer.

Then I double clicked the button to take me back to the code window and it
recreated the sub as below.

\\\
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

End Sub
///

Obviously, this isn't going to work as the base method is public
overridable...
Seems to be a limitation of the designer. Nevertheless, I don't
understand why you declare the handler as 'Overridable' in the base
form. Usually, you can override methods called 'On*' in the base form.

I changed the sub declaration to Public Overrides and the
error went away, but when I put code in the sub, it was executed twice when I ran the form.

Are you sure? Maybe you want to remove the handler defined in the base
form (notice that it's an event handler)!

\\\
RemoveHandler Me.Button1.Click, AddressOf MyBase.Button1_Click
///

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Hi Herfried,

I was following the "Developing Windows Forms applications with Visual
Basic.NET" seminar found here:
http://msdn.ms.demoservers.com/skins/msdn-us/login.htm

In here, they did precisely what I did, changed the default event of the
button click to public overridable, then overrode it in the inherited

form. I was merely following the examples as, though I'm an experienced VB6
programmer, I've only just got around to learning .NET so was deliberately
starting at the beginning, especially as I've never used an inherited form
before (used to templates...)

I just find it rather silly that double clicking the button on the inherited form (in VS .NET 2003 Pro), creates a default event code segment which
cannot be executed until you change it to Public Overrides and remove the
handler code at the end of the sub declaration.

Lorne

[Vijayakrishna Pondala]

For me, the button is appearing in designer.. but not when showing the
inherited form :-(

"Johan Jooris" <jo**********@hotmail.com> wrote in message
news:Z_**********************@phobos.telenet-ops.be...

Hi,

I was also experimenting with visual inheritance of forms and I encountered the following problem, which keeps me from using visual inheritance:
I designed a simple base form, with eg a buttoncontrol anchored at the
right - bottom corner.
I then changed the modifier of the button from friend to protected friend.

I added a new inherited forms, which inherits from this base form, adn I
change the size of the form.
When closing the form and reopening it in the designer, the button is placed somewhere on the screen, but not on the place where it should, ie x pixels
from the right, y pixels from the button.

What am I doing wrong, or is it a bug in the vs

"Lorne Smith" <[e-mail]> schreef in bericht
news:ez*************@tk2msftngp13.phx.gbl...

Hi,

First, sorry for the crosspost, but it seemed appropriate... :)

I've come accross what I consider to be a bug, but I don't know if it's
already known or not. (VS .Net 2003 Pro - VB.Net)

Whilst playing with inherited forms, I created a simple base form containing

a single button. I set this buttons' Click event to be public overridable and put "me.Close" in the code.

I then built the project and added a new inherited form using this base
form. All well so far. Now, I then went to the code view of the

inherited

form, chose the Overridable Button_Click event which gave me the

following:

\\\
Public Overrides Sub Button1_Click(ByVal sender As Object, ByVal e As
System.EventArgs)

End Sub
///

All well and good. Code inserted in here works fine. However, for some
reason I deleted this sub from the code and went to the designer. Then I double clicked the button to take me back to the code window and it
recreated the sub as below.

\\\
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

End Sub
///

Obviously, this isn't going to work as the base method is public
overridable... I changed the sub declaration to Public Overrides and the error went away, but when I put code in the sub, it was executed twice

when

I ran the form. Now I realised this is because both the base form and the inherited form are handling the event, but my question is, WHY did the
double click of the control create the event in such as unusable manner?

It

seems a little silly to create the event as Private, when the base

method is

Public Overridable!!

Is this known about already?

Regards

Lorne

[Rob Richardson]

Armin,

I'm a VB6 programmer just starting in VB.Net. Could you please explain what
you meant when you said that in theory, there could be several procedures in
a base class, all handling a button's Click event? I would have thought
that there could only be one event handler for a given event. How does VB
..Net decide which procedure to use when an event fires? Or does it run all
handlers associated with that event? If that's the case, how does it
determine which order to run them in?

Thanks!

Rob

"Armin Zingler" <az*******@freenet.de> wrote in message
news:O0**************@TK2MSFTNGP11.phx.gbl...

<snip>

In theory you can have several procedures in the base class, all handling
the button's click event. Some of the procedures might be private, some
public, some are overridable, some not. Do you expect the procedure,
generated in the derived form when you double-click the button (which does
not work here with me (VB 2002?)), to be overridable, public or private? It would be ambiguous because there are procedures with different modifiers in the base class handling the same event.
--
Armin

[Armin Zingler]

"Rob Richardson" <th*****@n2net.net> schrieb

I'm a VB6 programmer just starting in VB.Net. Could you please
explain what you meant when you said that in theory, there could be
several procedures in a base class, all handling a button's Click
event?

Private Sub Sub1( _
ByVal sender As System.Object, ByVal e As System.EventArgs) _
Handles Button1.Click

End Sub

Private Sub Sub2( _
ByVal sender As System.Object, ByVal e As System.EventArgs) _
Handles Button1.Click

End Sub

Both procedures (in the same Form) handle the Button's Click event.

I would have thought that there could only be one event
handler for a given event.
There can be none, one, several.
How does VB .Net decide which procedure
to use when an event fires? Or does it run all handlers associated
with that event?
Yes, it runs them all.
If that's the case, how does it determine which
order to run them in?

The order is undefined, or at least it shouldn't matter.
A Delegate is like a function pointer. An event is like a collection of
delegates. Raising an event means calling all delegates that have been added
to the event. In the example above, Sub1 and Sub2 have been added, so both
are called when the button raises the Click event.

See also:
http://groups.google.com/groups?selm...TNGP12.phx.gbl
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Jay B. Harlow [MVP - Outlook]]

Rob (& Armin),
The ease with which you can add multiple handlers for an event or multiple
events to a single handler. IMHO is one of the cooler things about .NET that
makes it so much easier then VB6!

To extend Armin's sample a little:

Private Sub Sub2( _
ByVal sender As System.Object, ByVal e As System.EventArgs) _
Handles Button1.Click, Button2.Click, Button3.Click

End Sub
Sub1 will only be executed on Button1 click, however Sub2 will be executed
for Button1, Button2 or Button3 click event. (As Armin stated, the
Button1.Click event will actually be handled by both Sub1 & Sub2).

Yes you can do it in VB6 with multiple subroutines, however you wind up with
multiple subroutines! With the new Handles syntax you can use "just the
right amount" of subroutines...

Hope this helps
Jay

"Armin Zingler" <az*******@freenet.de> wrote in message
news:uU**************@tk2msftngp13.phx.gbl... "Rob Richardson" <th*****@n2net.net> schrieb

I'm a VB6 programmer just starting in VB.Net. Could you please
explain what you meant when you said that in theory, there could be
several procedures in a base class, all handling a button's Click
event?

Private Sub Sub1( _
ByVal sender As System.Object, ByVal e As System.EventArgs) _
Handles Button1.Click

End Sub

Private Sub Sub2( _
ByVal sender As System.Object, ByVal e As System.EventArgs) _
Handles Button1.Click

End Sub

Both procedures (in the same Form) handle the Button's Click event.

I would have thought that there could only be one event
handler for a given event.

There can be none, one, several.

How does VB .Net decide which procedure
to use when an event fires? Or does it run all handlers associated
with that event?

Yes, it runs them all.

If that's the case, how does it determine which
order to run them in?

The order is undefined, or at least it shouldn't matter.
A Delegate is like a function pointer. An event is like a collection of
delegates. Raising an event means calling all delegates that have been

added to the event. In the example above, Sub1 and Sub2 have been added, so both
are called when the button raises the Click event.

See also:
http://groups.google.com/groups?selm...TNGP12.phx.gbl

--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html