I would like to have menu items a main menu bar that represent the days
of the week.  When you click on them they alternate from checked to
unchecked.  Right now I have 7 subs that look like this one:

Private Sub SunMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles SunMenuItem.Click
    If SunMenuItem.Checked Then
        SunMenuItem.Checked = False
    Else
        SunMenuItem.Checked = True
    End If
End Sub

I would like to use the same sub to handle all 7 menu items.  How would
I write this?

Hello cj,

private sub Form_Load(...)

    AddHandler MenuItem1.Click, AddressOf MenuItemClickHandler
    AddHandler MenuItem2.Click, AddressOf MenuItemClickHandler
    ...
    AddHandler MenuItemN.Click, AddressOf MenuItemClickHandler

End Sub

Private Sub MenuItemClickHandler(byval sender as object, byval e as EventArgs)

    Dim tMenuItem as MenuItem = sender
    tMenuItem.Checked = Not tMenuItem.Checked

End Sub

Show quoteHide quote

I love the way you change the menu item checked on an off
(tMenuItem.Checked = Not tMenuItem.Checked) but I don't get the add
handler lines and I'm not sure how the sender is working in your
example.  Perhaps you can help me understand from this starting point.

Private Sub DaysMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles SunMenuItem.Click, MonMenuItem.Click,
TueMenuItem.Click, WedMenuItem.Click, ThuMenuItem.Click,
FriMenuItem.Click, SatMenuItem.Click
     'how do I use sender here to check or uncheck the item clicked?
End Sub

GhostInAK wrote:
Show quoteHide quote

Hi Again,
   First just a thought - you should probably only have one thread for this
discussion going at one time, IMHO.
   The AddHandler is a way of 'connecting' an event to a routine to handle
it at runtime.  Note that in Ghost's example that the MenuItemClickHandler
has no 'handles' clause at the end of it (unlike the other solutions you have
seen).  He connects the event to the routine at run time through the use of
AddHandler.
Hope this helps.
Show quoteHide quote

Agree on the thread but multiple people answer my question and I'm just
writing back to each of them instead of picking only one persons response.

what would be the advantage of using addhandler vs handles clause?


Terry wrote:
Show quoteHide quote

the AddHandler is done at runtime.  So, if you need to add controlls at
runtime you can also setup handlers at that time.  It also allows you to
change the way an event is handled, by using RemoveHandler in conjunction
with it.  In your case, I think it clearer to use the Handles clause.   But I
am also new to .Net myself and would like to hear others opinions.
Show quoteHide quote

Hello cj,

I was kind of hoping you'd take it to the next level on yer own.. ah well.

The advantage of AddHandler is that you do not need to modify any code in
order to include more menuitem objects at some later date.  Simply loop over
your menu items and call AddHandler.  Later when you add new menu items they
will be caught by the loop and added as well.  Depending on your menu structure
you may need to either tag the menu items you want included, or perhaps create
a new class which derives from Menuitem and check the object type.

Second, the sender argument of the event handler is the menuitem which is
being clicked.  But sender is passed as object, so you need to cast/convert
it to a MenuItem before you get intellisense.  It also eliminates the need
for late binding at runtime.

-Boo

Show quoteHide quote

Ok, I tried in debug to see what sender is
? sender
{System.Windows.Forms.MenuItem}
     [System.Windows.Forms.MenuItem]: {System.Windows.Forms.MenuItem}

but it doesn't explain much to me.  After running the first line of your
code I tried to see what tmenuitem is
{System.Windows.Forms.MenuItem}
     BarBreak: False
     Break: False
     Checked: False
     Container: Nothing
     DefaultItem: False
     Enabled: True
     FindHandle: 0
     FindShortcut: 1
     Handle: 2009465263
     Index: 3
     IsParent: False
     MdiList: False
     MdiListItem: Nothing
     MenuItems: {System.Windows.Forms.Menu.MenuItemCollection}
     MergeOrder: 0
     MergeType: Add
     Mnemonic: Nothing
     OwnerDraw: False
     Parent: {System.Windows.Forms.MenuItem}
     RadioCheck: False
     Shortcut: None
     ShowShortcut: True
     Site: Nothing
     Text: "Wednesday"
     Visible: True

That's a lot more info.  Don't know why I couldn't say ? sender but...
If Sub MenuItem is getting the sender by value and then it would seem we
are making a (well is it new) instance of a menu item and giving it the
same properties of the sender.  Well I just don't get how it sets the
original clicked menuitem on and off.

GhostInAK wrote:
Show quoteHide quote

Private Sub SunMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles SunMenuItem.Click, SunMenuItem2.Click,
SunMenuItem3.Click, SunMenuItem4.Click well you get the point i guess :-)
     If SunMenuItem.Checked Then
         SunMenuItem.Checked = False
     Else
         SunMenuItem.Checked = True
     End If
End Sub

regards

Michel Posseth [MCP]



Show quoteHide quote

yes but my goal is not to have all of them change SunMenuItem.  It needs
to change only the one that was clicked.

Private Sub DaysMenuItem_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles SunMenuItem.Click, MonMenuItem.Click,
TueMenuItem.Click, WedMenuItem.Click, ThuMenuItem.Click,
FriMenuItem.Click, SatMenuItem.Click
     'how do I use sender here to check or uncheck the item clicked?
End Sub


M. Posseth wrote:
Show quoteHide quote

cast sender to the sending object type and read the name property , this way
you can handle every control individual


regards

Michel Posseth [MCP]


Show quoteHide quote

It doesn't seem to have a name property.  I guess it's going by the
handle property or something.

{System.Windows.Forms.MenuItem}
     BarBreak: False
     Break: False
     Checked: False
     Container: Nothing
     DefaultItem: False
     Enabled: True
     FindHandle: 0
     FindShortcut: 1
     Handle: 2009465263
     Index: 3
     IsParent: False
     MdiList: False
     MdiListItem: Nothing
     MenuItems: {System.Windows.Forms.Menu.MenuItemCollection}
     MergeOrder: 0
     MergeType: Add
     Mnemonic: Nothing
     OwnerDraw: False
     Parent: {System.Windows.Forms.MenuItem}
     RadioCheck: False
     Shortcut: None
     ShowShortcut: True
     Site: Nothing
     Text: "Wednesday"
     Visible: True


Michel Posseth [MCP] wrote:
Show quoteHide quote

Hi cj,

Thank you for your post.

I think to fully understand why the SubMenuItem_Click can handles multiple
menuitem's click event, you need to understand what is Delegate and what's
the relationship between Event and Delegate.

A delegate is a class that can hold a reference to a method. Unlike other
classes, a delegate class has a signature, and it can hold references only
to methods that match its signature. A delegate is thus equivalent to a
type-safe function pointer or a callback. A delegate declaration is
sufficient to define a delegate class, for example:

    Public Delegate Sub EventHandler(sender as Object, e As EventArgs)

You will notice the parameter and return value matches your "Private sub
SunMenuItem_Click" which will handle the menu item click event. (The
default in Visual Basic is to pass arguments by value.)

An event is a message sent by an object to signal the occurrence of an
action. The action could be caused by user interaction, such as a mouse
clock, or it could be triggered by some other program logic. The object
that raises the event is called the event sender. The object that captures
the event and responds to it is called the vent receiver.

In event communication, the event sender class does not know which object
or method will receive (handle) the events it raises. What is needed is an
intermediary (or pointer-like mechanism) between the source and the
receiver. That's why Delegate come into play.

Custom event delegates are needed only when an event generates event data.
Many events, including the menuitem's click, do not generate event data. In
such situations, the event delegate provided in the class library for the
no-data event, System.EventHandler, is adequate. Since System.Object is the
ultimate base class of all classes in the .NET Framework, and you know that
your event handler will only handle the menu item's click event, you can
cast the sender to a strong type MenuItem. You will see its properties and
methods after you casted it to the strong type.

The Handles keyword and the AddHandler statement both allow you to specify
that particular procedures handle particular events, but there are
differences. The AddHandler statement connects procedures to events at run
time. Use the Handles keyword when defining a procedure to specify that it
handles a particular event.

Some referneces:

#Handling and Raising Events
http://msdn2.microsoft.com/en-us/library/edzehd2t.aspx

#Arguments Passing By Value and By Reference
http://msdn2.microsoft.com/en-us/library/ddck1z30.aspx

Hope this helps. Please feel free to post here if anything is unclear.


Regards,
Walter Wang (waw***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

same sub, multiple control click events
OpenFileDialog
how to search a datatable-can I use sql on a vb2005 datatable?
How to filter by File Type ?
Navigate through a dataset
Default MessageBox Title
Delegates: String or Integer
System.Management VS WbemScripting
Reference to a control error. Toolstrip
Unicode Application Question