Clicking an array of labels in VB.net vs VB 6

[C]

In VB6 I could click an array of labels with Label1_Click (Index). How
do I do this in VB.net?

In VB.net, I created an array of labels by Dim Label1 as Label, and
then Label1(1) = Label101, Label1(2) = Label102, etc.

I can write Label101_Click, but it would be too messy to copy the code
to 32 labels.

Thanks.

 

[Tom Shelton]

C expressed precisely :

In VB6 I could click an array of labels with Label1_Click (Index). How
do I do this in VB.net?

In VB.net, I created an array of labels by Dim Label1 as Label, and
then Label1(1) = Label101, Label1(2) = Label102, etc.

I can write Label101_Click, but it would be too messy to copy the code
to 32 labels.

Thanks.

A single event handler can handle multiple controls. Assuming you have
VS2008

1. In the designer, select all of the lables you want to be assigned
to the event.

2. In the properties window, select the little lighting bolt icon.
This will show the events of the controls. In the event you want to
share, type the name of the procedure - such as LabelClick. Hit Enter.

VS will create a sub that looks something like this (I did mine with
buttons - but it works the same for all controls, in fact, as long as
the event shares the same signature - they don't even have to be the
same type of control):

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

End Sub

Now, if any of the 3 buttons are clicked, this sub will be called. You
can differentiate which control was clicked using the sender argument.

Private Sub ButtonClick(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button3.Click, Button2.Click, Button1.Click
MessageBox.Show(DirectCast(sender, Control).Text)
End Sub

And here's another example using different types of controls:

Private Sub ButtonClick(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click, Label1.Click
MessageBox.Show(DirectCast(sender, Control).Text)
End Sub

..NET events are much more powerful then VB6 control arrays once they
are understood.

 

[C]

C expressed precisely :





A single event handler can handle multiple controls.  Assuming you have
VS2008

1.  In the designer, select all of the lables you want to be assigned
to the event.

2.  In the properties window, select the little lighting bolt icon.  
This will show the events of the controls.  In the event you want to
share, type the name of the procedure - such as LabelClick.  Hit Enter.

VS will create a sub that looks something like this (I did mine with
buttons - but it works the same for all controls, in fact, as long as
the event shares the same signature - they don't even have to be the
same type of control):

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

End Sub

Thanks. This will be less messy, but Handles Label101.Click,
Label102.Click.... upto Label132 will not be too nice. May be I can
put it in 4 subroutines, since the code is going to be hardly about 5
lines.

Now, if any of the 3 buttons are clicked, this sub will be called.  You
can differentiate which control was clicked using the sender argument.

Private Sub ButtonClick(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button3.Click, Button2.Click, Button1.Click
        MessageBox.Show(DirectCast(sender, Control).Text)
End Sub

And here's another example using different types of controls:

Private Sub ButtonClick(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click, Label1.Click
        MessageBox.Show(DirectCast(sender, Control).Text)
End Sub

.NET events are much more powerful then VB6 control arrays once they
are understood.

I have started to realise that VB.net in general is quite powerful,
but the learning curve is steep.

What makes this worse is that logic is not always visible. I
particularly have difficultes understanding Graphics objects and how
they are stuck to Forms, etc.

 

[Cor]

What makes this worse is that logic is not always visible. I
particularly have difficultes understanding Graphics objects and how
they are stuck to Forms, etc.

In my opinion much more then in VB6.

Have a look in Solution Explorer in the top and click that little button
Show all files.
All logic becomes now visible in the YourForm.designer.vb

In VB6 I only saw this in Source Safe as a kind of clumsy resource
incorporated in the code.

Cor

 

[Tom Shelton]

C brought next idea :

Thanks. This will be less messy, but Handles Label101.Click,
Label102.Click.... upto Label132 will not be too nice. May be I can
put it in 4 subroutines, since the code is going to be hardly about 5
lines.

You can always put the labels in a list and then dynamically attach the
handler using AddHandler if you think the other way is to messy...

 

[C]

In my opinion much more then in VB6.

Have a look in Solution Explorer in the top and click that little button
Show all files.
All logic becomes now visible in the YourForm.designer.vb

In VB6 I only saw this in Source Safe as a kind of clumsy resource
incorporated in the code.

Cor

I was referring to something else. When trying to learn how to use the
graphics objects, I am not able to figure out how I should Dim them
and where to have e.Graphics.***. I think there is little sense or
logic in that.

g.DrawLine, g.DrawRectangle, etc. is easy to understand, but the rest
does not sound very consistent to me.

 

[C]

C brought next idea :







You can always put the labels in a list and then dynamically attach the
handler using AddHandler if you think the other way is to messy...

Sorry I am a beginner, and still do not know what a handler is, what
dynamic attachment is, or how to put labels in lists. I will
appreciate a couple of lines of explanation.

For the moment, I have put 8 labels at a time for each subroutine.

Thanks.

 

[Tom Shelton]

After serious thinking C wrote :

Sorry I am a beginner, and still do not know what a handler is, what
dynamic attachment is, or how to put labels in lists. I will
appreciate a couple of lines of explanation.

For the moment, I have put 8 labels at a time for each subroutine.

Thanks.

Option Strict On
Option Explicit On

Imports System
' form with 11 lables...
Public Class Form1

Private Sub LabelClick(ByVal sender As System.Object, ByVal e As
System.EventArgs)
MessageBox.Show(DirectCast(sender, Control).Text)
End Sub

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
For i As Integer = 1 To 11
Dim lbl As Label = DirectCast(Me.Controls("Label" & i),
Label)
AddHandler lbl.Click, AddressOf LabelClick
Next
End Sub
End Class

 

[Cor]

the documentation on MSDN and the according samples about graphics are in my
idea very confusing. It seems that you have to do everything in the method
which handles the paint event. (I know it sounds confusing).

Be aware that you can create a graphic in a form with CreateGraphic while
there are also methods where you can create it from the handler.

If you have created a graphic (an image or a bitmap) then suddenly it
becomes suddenly less difficult.

What the newer VB more confusing are all those classes which you can use and
are in the Net framework. Net. That are not anymore only Microsoft Visual
Basic namespaces, but also many others.

Have a look a this.

http://msdn.microsoft.com/en-us/library/ms229335.aspx

(In fact most is what you called API's in VB6.)

Cor

 

[C]

After serious thinking C wrote :









Option Strict On
Option Explicit On

Imports System
' form with 11 lables...
Public Class Form1

    Private Sub LabelClick(ByVal sender As System.Object, ByVal e As
System.EventArgs)
        MessageBox.Show(DirectCast(sender, Control).Text)
    End Sub

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
        For i As Integer = 1 To 11
            Dim lbl As Label = DirectCast(Me.Controls("Label" & i),
Label)
            AddHandler lbl.Click, AddressOf LabelClick
        Next
    End Sub
End Class

This is too advanced for me. To understand this I will have to figure
four new things. I hope I will do it some day, but for now, it looks
complicated. Thanks.

 

[C]

the documentation on MSDN and the according samples about graphics are inmy
idea very confusing. It seems that you have to do everything in the method
which handles the paint event. (I know it sounds confusing).

Be aware that you can create a graphic in a form with CreateGraphic while
there are also methods where you can create it from the handler.

There seem to be a few different ways, but the syntax used in VB.net
does not sound logical to me. I have learnt one way, which is good
enough for now, but I am left with a feeling that I don't really know
how it works.

If you have created a graphic (an image or a bitmap) then suddenly it
becomes suddenly less difficult.

I think this part was easier for me. I am able to do all the drawing I
need (plots, lines, rectangles) with g.DrawLine and g.FillRectangle,
etc. How I stick this to the Form I don't quite understand. It works
because I have emulated from other code but I don't understand what
Dim g as Graphics = Graphics.FromImage (formImage)
and
e.Graphics.DrawImage(formImage,0,0)
really do. These statements don't sound sensible to me.

 

[Cor]

e is mostly used (done by the designer) as an evertargument.

It returns information from the event. In the paint eventargs it contains a
graphic so you can do there.
e.graphic

e is almost a keyword in all net program classes, while it is in fact not a
keyword.

 

[C]

e is mostly used (done by the designer) as an evertargument.

It returns information from the event. In the paint eventargs it containsa
graphic so you can do there.
e.graphic

I see the point there. Thanks for this.

e is almost a keyword in all net program classes, while it is in fact nota
keyword.

Yes, but apparently e can have different methods for different events,
and the programmer needs to learn all this before he can use this
stuff effectively.

 

[Tom Shelton]

C presented the following explanation :

I see the point there. Thanks for this.


Yes, but apparently e can have different methods for different events,
and the programmer needs to learn all this before he can use this
stuff effectively.

While it is not a requirement, the accepted pattern for event
signatures is this:

Sub EventSub (ByVal sender As Object, e As EventArgs)

sender is the object that raised the event. So, if this event is
attached to the click event of button1 and you click button1, sender
will be a reference to button1. This argument becomes useful when you
have multiple controls tied to the same event handler.

e is an object of type EventArgs or a subclass of EventArgs. It is
there to provide the ability to pass information in and out of the
event. The base EventArgs really does nothing - it is simply a place
holder. Other events, such as the MouseMove event, will supply you
with additional data so the pass you a subclass of EventArgs. In the
case of MouseMove that would be a an instance of MouseEventArgs.

sender and e are not keywords, they can really be called anything. And
there is not requirement that an event signature take any arguments at
all. This is simply the convention used by the framework, and by most
..net programmers.

So, your right - e can have different methods/properties for different
events. But, knowing that is half the battle. When you use a new
event, it's always wise to look at the type of e, and if it's not
EventArgs, then you might want to look at it more closely and see what
you are being passed - or can return, as in the Cancel property of the
FormClosingEventArgs.

 

[C]

C presented the following explanation :








While it is not a requirement, the accepted pattern for event
signatures is this:

Sub EventSub (ByVal sender As Object, e As EventArgs)

sender is the object that raised the event.  So, if this event is
attached to the click event of button1 and you click button1, sender
will be a reference to button1.  This argument becomes useful when you
have multiple controls tied to the same event handler.

Great. This will be useful for me on some forms.

e is an object of type EventArgs or a subclass of EventArgs.  It is
there to provide the ability to pass information in and out of the
event.  The base EventArgs really does nothing - it is simply a place
holder.  Other events, such as the MouseMove event, will supply you
with additional data so the pass you a subclass of EventArgs.  In the
case of MouseMove that would be a an instance of MouseEventArgs.

sender and e are not keywords, they can really be called anything.  And
there is not requirement that an event signature take any arguments at
all.  This is simply the convention used by the framework, and by most
.net programmers.

So, your right - e can have different methods/properties for different
events.  But, knowing that is half the battle.  When you use a new
event, it's always wise to look at the type of e, and if it's not
EventArgs, then you might want to look at it more closely and see what
you are being passed - or can return, as in the Cancel property of the
FormClosingEventArgs.

OK. It is probably easy to check this with the AutoComplete feature.
Thanks.