[RESOLVED] callinf code inside a menu

[B61Nuke]

Hello, I have this snippet ...

Private Sub CmdClear_Click_1(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles CmdClear.Click
        TxtCompany.Text = ""
        TxtContact.Text = ""
        TxtAddress.Text = ""
        TxtCity.Text = ""
        TxtState.Text = ""
        TxtZipCode.Text = ""
        TxtLandPhone.Text = ""
        TxtCell.Text = ""
        TxtFax.Text = ""
        TxtEmail.Text = ""
        TxtDate.Text = ""
        TxtID.Text = ""
    End Sub

I want to execute the above code from inside this snippet ...

Public Sub CmdSave_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles CmdSave.Click
        Customer.Company = TxtCompany.Text
        Customer.Contact = TxtContact.Text
        Customer.Address = TxtAddress.Text
        Customer.City = TxtCity.Text
        Customer.State = TxtState.Text
        Customer.ZipCode = TxtZipCode.Text
        Customer.LandPhone = TxtLandPhone.Text
        Customer.Cell = TxtCell.Text
        Customer.Fax = TxtFax.Text
        Customer.Email = TxtEmail.Text
        Customer.DateCreated = TxtDate.Text
        Customer.ID = TxtID.Text
        OpenAccount()
        AccountLastRecord = AccountLastRecord + 1
        FilePut(AccountFileNum, Customer, AccountLastRecord)
        FileClose(AccountFileNum)
        MsgBox("File Saved")
    End Sub

in the old VB6 I could use

 cmdclear_click"

How does one do this in .net?

[jmcilhinney]

You can just call the method in VB.NET too, but you shouldn't. Is CmdClear a Button? If so, call its PerformClick method. If not, take the code out of CmdClear_Click_1 and put it in a separate method. You can then call that method from CmdClear_Click_1 and CmdSave_Click.

[B61Nuke]

You can just call the method in VB.NET too, but you shouldn't.

Why not?

Is CmdClear a Button?

Yes

If so, call its PerformClick method.

like this? ...

CmdClear_Click_1(CmdClear,Nothing)

If not, take the code out of CmdClear_Click_1 and put it in a separate method. You can then call that method from CmdClear_Click_1 and CmdSave_Click.

Why take the code out of CmdClear_Click_1 ? Is your reason to make the code more usuable thruout the form? I do not see or understand why I should put it in a sub. If it is only being used in this form, why not simply call it from where it is? Please explain.

[jmcilhinney]

Because event handlers should handle events and that's all. It's one of those things that is just good practice.

like this? ...

CmdClear_Click_1(CmdClear,Nothing)

Given that there's no PerformClick method anywhere in that code, I'd say probably not. Don;t try to read anything into it. Just do exactly what I said: call CmdClear's PerformClick method.

Also, your title seems irrelevant because, if CmdClear is a Button, I would assume that CmdSave is too. There's no menu at all as far as I can see.

Finally, I know that the term "command button" was used in VB6 and old habits die hard but in VB.NET a Button is a Button. The term "command" has no relevance in VB.NET so the the prefix "Cmd" has no relevance. If you want a meaningful prefix then "btn" would be more appropriate. Hungarian notation is (thankfully) falling out of favour more and more and it can't happen fast enough for me. Meaningful names like "saveButton" and "clearButton" are clearer to everyone.

[B61Nuke]

Because event handlers should handle events and that's all. It's one of those things that is just good practice.

OK. I'll have to read up on this and get a full definition somewhere. Must be an underlying reason as to why. I'll track it down.

Given that there's no PerformClick method anywhere in that code, I'd say probably not. Don;t try to read anything into it. Just do exactly what I said: call CmdClear's PerformClick method.

You got me baffled. I'll have to look that up as well as you didn't post an example.

Also, your title seems irrelevant because, if CmdClear is a Button, I would assume that CmdSave is too.

Yes. It is a button.

There's no menu at all as far as I can see.

Lost me on this statement.

Finally, I know that the term "command button" was used in VB6 and old habits die hard but in VB.NET a Button is a Button. The term "command" has no relevance in VB.NET so the prefix "Cmd" has no relevance. If you want a meaningful prefix then "btn" would be more appropriate. Hungarian notation is (thankfully) falling out of favour more and more and it can't happen fast enough for me. Meaningful names like "saveButton" and "clearButton" are clearer to everyone.

Semantics. No biggie. I will change them to reflect current protocol.

Thanks for all your assistance.

[B61Nuke]

Button1.PerformClick()

Found it. It was right under my nose.

[jmcilhinney]

An event handler has two parameters: 'sender' is supposed to be the object that raised the event and 'e' is supposed to be the data for the event. If you call an event handler directly then you have to fake these arguments. That's not a big deal if you don't actually use the parameters inside the event handler but, if you do, fake values will obviously be a problem. If you don't call event handlers directly then you never have to pass fake arguments and and you can never inadvertently use fake arguments. It's not that hard to make sure that you don't inadvertently use fake arguments but there's also a way to make sure you can't: don't call event handlers directly. Frankly, it's one of those things that just feels wrong.

The title of your thread says "inside a menu" yet your post is all about Buttons. Your thread title seems irrelevant to the topic of the thread.

The conventions you use in naming are up to you but the recommendation for variables is camel casing (first letter lower case, each subsequent word starting with an upper case letter) and generally full words and meaningful names.

[B61Nuke]

An event handler has two parameters: 'sender' is supposed to be the object that raised the event and 'e' is supposed to be the data for the event. If you call an event handler directly then you have to fake these arguments. That's not a big deal if you don't actually use the parameters inside the event handler but, if you do, fake values will obviously be a problem. If you don't call event handlers directly then you never have to pass fake arguments and and you can never inadvertently use fake arguments. It's not that hard to make sure that you don't inadvertently use fake arguments but there's also a way to make sure you can't: don't call event handlers directly.

Now that is good information. Thank you for that.

The conventions you use in naming are up to you but the recommendation for variables is camel casing (first letter lower case, each subsequent word starting with an upper case letter) and generally full words and meaningful names.

Considering that only I will have to see it in the future, I am going to stick with what has worked for over 30 years. I'm used to it. The variables I use are very easily understood by me , however when I post for help I will convert the code snippet that I post and title my post for easier understanding. Thanks for the assist. You must be an excellent coder to be so precise.