How can we use the "sender" parameter in a click event?

[leonlai]

Hi, everybody

I am learning how to program Excel using VB .NET and am still very much a newbie.

I am trying to understand how we can use the "sender" parameter in a click event.

I got this interesting sample from the net:

Private Sub Button_Click(ByVal sender As Object, ByVal e As EventArgs) _
                                               Handles Button1.OnClick, Button2.OnClick

        Dim s As String
        If sender Is Button1 Then
            s = "button1"

        ElseIf sender Is Button2 Then
            s = "button2"

        End If

        MsgBox("You pressed: " & s)

    End Sub

Unfortunately, the article does not explain what code to put in the click events of Button1 and Button2


I tried the following (for Button1), but it does not work:

Private Sub Button1_OnClick(ByVal sender As System.Object, _ 
ByVal control As AddinExpress.MSO.IRibbonControl, _
ByVal pressed As System.Boolean) Handles Button1.OnClick

        Button_Click(Button1)      '// DOES NOT WORK!!

End Sub

The error message is:

Argument not specified for parameter 'e' of Private Sub Button_Click (sender As Object, e As System.Event Args).

Can anybody help?

Thanks
Leon

[Goggy]

Both click events are handeld in the first example.... notice "Handles Button1.OnClick, Button2.OnClick"

and i would convert the sender object to a button object and show its name...
somthing like

Msgbox(DirectCast(sender,System.Windows.Forms.Button).Name))

[leonlai]

Hi, Goggy

Thanks for your reply.

I understand the mechanism now.

However, since I use Add-in Express to create the buttons on the Ribbon, I must do some research to adapt your code to my example. I am not using a Windows.Forms.Button.

Best Regards,
Leon

[techgnome]

the example your'e trying to follow is a bad one to follow for you case... it's a good one to follow if and only if you want to handle multiple buttons from the same handler, which isn't common. It's rare to want to use the sender parameter. Normally you just create the button or control (what ever it may be) and you simply create the event handler you want to handle (be it a click or onChange, or what ever) and you write the code you need in that event handler.

since you are writing an add-in for Excel, you may want to look at examples/books that deal specifically with Office Add-ins and not at VB in general as there are going to be some differences.


-tg

[leonlai]

Hi, techgnome

Thanks for your reply.

In fact I am not using sender for any project at the moment.

I just found an article on the web. And as I never understood what "sender" does, I thought it would be interesting to try the example in the article.

This would be serve as a start in my learning path.

Best Regards,
Leon

[si_the_geek]

sender is the object that caused the event to happen... which in the examples are buttons.

In Button1_OnClick the sender will always be Button1, because that is the only object listed in the Handles clause.

In Button_Click it can be either Button1 or Button2, because they are both listed in the Handles clause.


Sometimes you want to have similar things happening in the events of two or more controls. For example you could have a button that saves the document to a particular location, and another button that saves it to another location.

If the code is fairly long you won't want to write the code twice (or have two copies of it, because when you change one you need to remember the other one and change that too), so listing multiple objects in the Handles clause allows you to re-use the code without those issues - but when you do it, you need to check the sender to alter the behaviour as appropriate (in this saving example, store the relevant location to a variable that can be used by the code that does the saving).


Unfortunately to make it a bit more awkward, you can add more controls without listing them in the Handles clause (by using AddHandler), so knowing what might cause an event to fire (and be stored in sender) isn't as simple as looking at the Handles clause. As a general rule you don't need to worry about it, unless you are reading code that somebody else has written (and if it is a concern, they would probably already have used sender inside the event).

[techgnome]

It doesn't do anything... what it is is a reference to the object that raised the event.
So if you have an event handler that handles one control... say a button, hen sender will have a reference to that button. In the case of a TextCanged event of a text box, it would be the text box that raised the event. Normally in the case of single control events, which is perhaps 80% of the time, sender is redundant and useless, but there are times when you want a single handler to handle multiple controls, as in the example you posted first. In those cases, you need to know which button was clicked so you know what action to take. That's where sender comes in handy. You DirectCast is as a button (it comes in as an Object) and then you can then get to it's .Name property (and any other property it has) and then take what ever action you need to at that point.

Take the Save and Save As.. functions... they are virtually identical, the only real difference is the name of the file under which the file gets saved as... so you could have one handler that handles both buttons... in the handler you would use DirectCast to convert sender to Buttons, get the .Name (or I'd probaly use .Tag to differentiate between the two) if the user clicked Save, I'd simply call the Save routine. But if they clicked the Save As... button, I'd call the GetNewFile routine, which displays the file name picker, allow them to pick a nw path and filename, return that, set that as the new file, then call the same Save routine that the save button would have called. Boom.

Now let's say there's something that needs to be done, some sort of validation that needs to be done before each save every time... I can simply write a Validate routine, and then in my one handler, I add a call to Validate right before Save... boom, done... I only have to change it in one spot because both Save and Save As... use the same handler. If I had a handler for each button, it would have required two changes, one for each. Yes, I could have added it to Save, but then that violates the principle that routines should do one thing and one thing only. Save should do save things and only save things. Validate should do validate things and only validate things. The handler is doing handler things and only handler things.

Hope this is helping.

-tg

[leonlai]

Hi, Goggy

I think you would be happy to know that I have been able to make the code work now - just by changing the signature of the sub:

Private Sub Button_OnClick(ByVal sender As System.Object, _
ByVal control As AddinExpress.MSO.IRibbonControl, _
ByVal pressed As System.Boolean) Handles Button1.OnClick, Button2.OnClick

Without your help, I would still be struggling, trying to put codes in Button1 and Button2.
Of course, I could not expect anybody to help me on the Add-in Express part.

Now, I have plenty of ideas how to use sender in real-life applications!

Best Regards,
Leon

[leonlai]

Hi, techgnome

Here is the site I found the example:

https://stackoverflow.com/questions/...ender-used-for

I had to adapt it to my situation.
I use Add-in Express to create the buttons for me. It is clear that the code will not work for me without modification.
It works perfectly if I create my 2 buttons in a Windows Forms.

But it takes a slight modification (concerning namespace) to make it work for me.

Thanks for your explanation. It's very enlightening.

Best Regards,
Leon

[leonlai]

Hi, si_the_geek

Thanks for your reply.

Sometimes you want to have similar things happening in the events of two or more controls. For example you could have a button that saves the document to a particular location, and another button that saves it to another location.

Now, this is exactly my problem!
Now that I have understood the meaning of sender, I can attack my real-life problems.

When I post questions on any forum, I try to illustrate my questions with the simplest examples possible.
This is the only way to ensure people answer my questions.

Once I get the trick, I can tackle my real problems which are too complex to post on the forum.

But since you have guessed my intention, I wrote these few lines...

Best Regards,
Leon