Got myself in a pickel ...
Got myself in a pickel ...
Got myself in a pickel ...
Got myself in a pickel ...
Got myself in a pickel ...
Got myself in a pickel ... Got myself in a pickel ... Got myself in a pickel ... Got myself in a pickel ... Got myself in a pickel ... Got myself in a pickel ... Got myself in a pickel ... Got myself in a pickel ...
Got myself in a pickel ... Got myself in a pickel ...
Got myself in a pickel ...
Go Back  Xtreme Visual Basic Talk > > > Got myself in a pickel ...


Reply
 
Thread Tools Display Modes
  #1  
Old 06-16-2010, 04:58 PM
TRSDOSBasic79's Avatar
TRSDOSBasic79 TRSDOSBasic79 is offline
Contributor
 
Join Date: Oct 2003
Location: Pennsylvania
Posts: 422
Default Got myself in a pickel ...


I have setup a small app to track company info and purchases, etc. I decided to move a panel with textboxes from Form1 to Form2. I did not move any code and after some thinking on it, I decided to move the panel back to form1 and continue with my original plan. Trouble came when I tried to run the app. The ide displays it perfectly but none of my code is working. Here is what I noticed ...

My original code from a textbox ...
Code:
Private Sub TxtCompany_GotFocus(ByVal sender As Object, ByVal e As System.EventArgs)
        If TxtCompany.Text <> "" Then
            TempCompany = TxtCompany.Text
            TxtCompany.Text = ""
        End If
End Sub
This used to work before I moved the panel. I went back to txtCompany's events and doubleclicked "got focus" to start a new event to see if it was the same as what I already had. It displayed this ...

Code:
 Private Sub TxtCompany_GotFocus1(ByVal sender As Object, ByVal e As System.EventArgs) Handles TxtCompany.GotFocus

End Sub
It's like I somehow created a dup of panel and lost it's original status and now the ide wants me to make a copy of the code. How do I get the ide to see the panel and it's contents as the original?
Reply With Quote
  #2  
Old 06-16-2010, 05:23 PM
PlausiblyDamp's Avatar
PlausiblyDampGot myself in a pickel ... PlausiblyDamp is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Nov 2003
Location: Newport, Wales
Posts: 2,058
Default

Probably easiest to just manually had the relevant Handles .... to the end of each of the event handlers.
__________________
Intellectuals solve problems; geniuses prevent them.
-- Albert Einstein

Posting Guidelines Forum Rules Use the code tags
Reply With Quote
  #3  
Old 06-16-2010, 05:51 PM
TRSDOSBasic79's Avatar
TRSDOSBasic79 TRSDOSBasic79 is offline
Contributor
 
Join Date: Oct 2003
Location: Pennsylvania
Posts: 422
Default

Thanks PD. It seems that the move just wiped the handles. LOL Here I thought it was a serious thing.
Reply With Quote
  #4  
Old 06-18-2010, 09:28 AM
AtmaWeapon's Avatar
AtmaWeaponGot myself in a pickel ... AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

Let's turn this into a lesson. PlausiblyDamp covered the "what" but not the "why", and knowing some of the implementation details of events can help open the door to some advanced techniques.

The "by hand" way to set up an event handler is to use the AddHandler statement. It's technically a Sub, but you use it like a keyword. It takes two parameters: an Event and a delegate that matches the event handler signature. I'm not going to dwell on defining those terms to keep this brief; if you're curious then ask.

So, let's say you have a button click event handler ready:
Code:
Sub Button_OnClick(ByVal sender as Object, ByVal e As EventArgs)
You tell your code to call this method when "Button1" is clicked by using the AddHandler statement; you might put this in your form's Load event handler:
Code:
AddHandler Button1.Click, AddressOf Button_OnClick
This is one of the few places where it's important to not use parenthesis after method names. The AddressOf statement is used to tell VB that we are not calling the method but we want to refer to ButtonOnClick() as a delegate. There's another way you could do this but it's idiomatic to use AddressOf.

Behind the scenes, this adds the Button_OnClick delegate to a list of delegates that will be called whenever Button1's Click event is raised. If you call AddHandler and add the same method twice, it will get called twice. If you ever want Button_OnClick() to not be called when the event is raised, there is a RemoveHandler statement that works as you might expect:
Code:
RemoveHandler Button1.Click, AddressOf Button_OnClick
VB .NET uses the Handles clause to set up event handlers from the designer. The Handles clause expects a comma-separated list of events. So, we could have had VB .NET wire up the event handler for us:
Code:
Sub Button_OnClick(ByVal sender As Object, ...) Handles Button1.Click
You could make the method work for several different events:
Code:
Sub Button_OnClick(...) Handles Button1.Click, ToolStripMenuItem1.Click
It's not magic. When the compiler sees these statements, it automatically adds AddHandler statements to your class's constructor. You might be able to use RemoveHandler to unwire event handlers in this manner, but it's not common.

The Handles clause can only be used to add event handlers for controls that exist when the form is created. It is not automatically rewired if you destroy the control and recreate it. If you need to do either of these, use the AddHandler and RemoveHandler statements instead.
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
  #5  
Old 06-21-2010, 01:21 PM
TRSDOSBasic79's Avatar
TRSDOSBasic79 TRSDOSBasic79 is offline
Contributor
 
Join Date: Oct 2003
Location: Pennsylvania
Posts: 422
Default

This handler stuff just baffles me. Are you basically stating that if I use the addhandler, that I can call operations of other objects?
Reply With Quote
  #6  
Old 06-21-2010, 01:49 PM
AtmaWeapon's Avatar
AtmaWeaponGot myself in a pickel ... AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

Could you clarify what you mean by "call operations of other objects"?

If you mean, "I can set up an event handler for an object that's not the current one" then yes, you can. AddHandler/RemoveHandler will work with any delegate, no matter what type the method belongs to.
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
  #7  
Old 06-21-2010, 02:05 PM
TRSDOSBasic79's Avatar
TRSDOSBasic79 TRSDOSBasic79 is offline
Contributor
 
Join Date: Oct 2003
Location: Pennsylvania
Posts: 422
Default

What I mean is say I have two Command buttons. From button1's click event, I could call button2's doubleclick event with a handler. Is that right?
Reply With Quote
  #8  
Old 06-21-2010, 02:14 PM
PlausiblyDamp's Avatar
PlausiblyDampGot myself in a pickel ... PlausiblyDamp is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Nov 2003
Location: Newport, Wales
Posts: 2,058
Default

The trick is not to think of it as the handler for button1's click event but a handler that is registered for that event. It can just as easily be registered for any other compatible event such as Button2's click event and so on.
__________________
Intellectuals solve problems; geniuses prevent them.
-- Albert Einstein

Posting Guidelines Forum Rules Use the code tags
Reply With Quote
  #9  
Old 06-22-2010, 05:55 AM
TRSDOSBasic79's Avatar
TRSDOSBasic79 TRSDOSBasic79 is offline
Contributor
 
Join Date: Oct 2003
Location: Pennsylvania
Posts: 422
Default

So... If there are 4 buttons on form1 and I add a handler registered to the click event to button1, I can perform click events for buttons 2,3,and 4. Right? What would the statements look like to do this?
Reply With Quote
  #10  
Old 06-22-2010, 06:36 AM
PlausiblyDamp's Avatar
PlausiblyDampGot myself in a pickel ... PlausiblyDamp is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Nov 2003
Location: Newport, Wales
Posts: 2,058
Default

You could simply list the other events after the handler e.g. if the code looked like
Code:
private Sub Button1_Click(sender as object, e as eventargs) Handles button1.click
you could just list the other events it will handle
Code:
private Sub Button1_Click(sender as object, e as eventargs) Handles button1.click, button2.click, button3.click
__________________
Intellectuals solve problems; geniuses prevent them.
-- Albert Einstein

Posting Guidelines Forum Rules Use the code tags
Reply With Quote
  #11  
Old 06-22-2010, 07:51 AM
TRSDOSBasic79's Avatar
TRSDOSBasic79 TRSDOSBasic79 is offline
Contributor
 
Join Date: Oct 2003
Location: Pennsylvania
Posts: 422
Default

Quote:
Originally Posted by PlausiblyDamp View Post
Code:
private Sub Button1_Click(sender as object, e as eventargs) Handles button1.click, button2.click, button3.click
so when you click button1, all 4 button click events would fire. correct?
If so, this can be handy.
Reply With Quote
  #12  
Old 06-22-2010, 08:12 AM
PlausiblyDamp's Avatar
PlausiblyDampGot myself in a pickel ... PlausiblyDamp is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Nov 2003
Location: Newport, Wales
Posts: 2,058
Default

The code I posted would result in the Button1_Click event firing if you clicked on any of the 3 buttons. If you have multiple event handlers then you can just bind the same event to them using "Handles Button1.Click" at the end of all of them.
__________________
Intellectuals solve problems; geniuses prevent them.
-- Albert Einstein

Posting Guidelines Forum Rules Use the code tags
Reply With Quote
  #13  
Old 06-22-2010, 08:34 AM
AtmaWeapon's Avatar
AtmaWeaponGot myself in a pickel ... AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

Quote:
Originally Posted by TRSDOSBasic79 View Post
so when you click button1, all 4 button click events would fire. correct?
If so, this can be handy.
You are confusing "event is raised" with "handler is called". At least I think so.

When you click Button1, it raises its Click event. Under the hood, the computer has a list of all event handlers for Button1.Click. Button1_Click() is one of them because the Handles clause causes VB to add it to the list. So when you click Button1, Button1_Click() is called. No other events are raised.

When you click Button2, it raises its own Click event. Again, Button1_Click() is in the list of handlers, so it gets called.

What's happening here is you have said, "I want the same method to be called if any event in this list is raised." You might do the same thing for all events, or you might look at sender or something else to determine which event was raised and do something slightly different.

It sounds like you're looking for a way to say "When Button1 is clicked, act as if these other buttons were clicked too." The solution to that is slightly different. Instead of using event handlers, you use normal methods. Let's reduce it to 2 buttons for simplicity. We'll say that, for some reason, Button1 should also do button 2's action when it is clicked, and button 2 should only do its own action. This is one way to solve the problem:
Code:
Sub Button1Action()
    MessageBox.Show("Button 1's action!")
End Sub

Sub Button2Action()
    MessageBox.Show("Button 2's action!")
End Sub

Sub Button1_Click(...) Handles Button1.Click
    Button1Action()
    Button2Action()
End Sub

Sub Button2_Click(...) Handles Button2.Click
    Button2Action()
End Sub
There isn't really a good way to do this with multiple event handlers. There are a few ways to hack it, but it's much more elegant to separate the action you want to do from when you want to do it; this gives you the ability to perform the action in multiple places.
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
  #14  
Old 06-22-2010, 04:16 PM
TRSDOSBasic79's Avatar
TRSDOSBasic79 TRSDOSBasic79 is offline
Contributor
 
Join Date: Oct 2003
Location: Pennsylvania
Posts: 422
Default

I completely understand the latter code snippet. I am grasping the handler code slightly.
Probably the reason handlers make no sense to me is when I see these two snippets of code they both are transferring control to subs. Am I wrong? I don't see why there is a need for both types of branches. The latter snippet is usually how I make my code. Can the handlers be used from a "Sub" to activate a button's click event? I think that was one of your examples in your lesson above. Correct? Still working with your code from the examples above. Thanks for the time guys. I know I'm thick headed.


Code:
Public Class Form1
    Sub Button_OnClick(ByVal sender As Object, ByVal e As EventArgs)
        MsgBox("code under button_onclick ")
    End Sub

    Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        AddHandler Button1.Click, AddressOf Button_OnClick
    End Sub

    Private Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click
        MsgBox("the click event of button1")
    End Sub
End Class


and your code for the buttons ...



Code:
Sub Button1Action()
    MessageBox.Show("Button 1's action!")
End Sub

Sub Button2Action()
    MessageBox.Show("Button 2's action!")
End Sub

Sub Button1_Click(...) Handles Button1.Click
    Button1Action()
    Button2Action()
End Sub

Sub Button2_Click(...) Handles Button2.Click
    Button2Action()
End Sub
Reply With Quote
  #15  
Old 06-22-2010, 06:21 PM
AtmaWeapon's Avatar
AtmaWeaponGot myself in a pickel ... AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

I'm not sure I understand the question, but I'll explain what your code snippet would do. If I give the wrong answer, try asking again.

Your code snippet sets up two event handlers for Button1.Click. When you click the button, you will see both dialogs. I would assume you would see the one with the "Handles" clause first, but the order of execution of event handlers isn't documented so you shouldn't rely on it.

Is it a good practice? Maybe. If you need to do two distinctly different things when the event is raised, there may be a benefit to having two different event handlers. However, I think this is more rare than having two different subs you call.

One reason I say this is you usually name event handlers something that makes it clear they are event handlers so it's easy to find them. You usually name Subs/Functions after what they do so it's easy to understand what they do. It's better to have a Sub with a descriptive name. For example, compare these two scenarios:
Code:
Sub Button1_Click(...) Handles Button1.Click
    ' 100 lines of code
End Sub
Code:
Sub Button1_Click(...) Handles Button1.Click
    SaveDocument()
End Sub

Sub SaveDocument()
    ' 100 lines of code
End Sub
In the 2nd case, it's much easier to understand what happens when you click the button. Imagine you took a week of vacation and came back to the application. If I asked you, "What's Button1_Click do?", don't you think it'd be harder to come up with the answer than if I asked, "What's SaveDocument() do?" It gets worse with multiple handlers. I've seen it on projects, and it usually looks like this:
Code:
Sub Button1_Click(...) Handles Button1.Click
    ' 100 lines of code
End Sub

' a few dozen other methods, maybe 150 lines later...

Sub Button1_Click1(...)
    ' 12 lines of code
End Sub
Now imagine coming back after that vacation and I ask you to change the code that saves the document. Which one is it, Button1_Click() or Button1_Click1()? Hard to tell, isn't it? What if it were written like this?
Code:
Sub Button1_Click(...) Handles Button1.Click
    SaveDocument()
    UpdateUI()
End Sub

Sub SaveDocument()
End Sub

Sub UpdateUI()
End Sub
Much easier to pick out where the document is saved, right? The other snippet (the one with multiple handlers) has another subtle problem. Like I said, the order in which event handlers are executed is not guaranteed. It's possible the first snippet would try to update the UI, then save the document, which might be invalid. There's not really a good solution to that problem, since anything that changes the order is relying on undocumented information that might change. Another subtle problem: when an event handler throws an exception and doesn't catch it, the handlers that were supposed to come after it won't be executed. There's no way around it. If you write your event handlers to call methods, you can set up Try..Catch blocks to make sure that everything gets done no matter what.

A rule of thumb that helps explain why it's worth the "extra work" to write the subs: You write code once, and read it many times. Optimize for code that's easier to read and understand. I have to re-read code I've already written 50+ times per day. If I save 10 seconds taking a shortcut but it costs me 5 seconds to remember the clever trick, then I cost myself a potential 250 seconds. If I spend an extra minute making it so that I can instantly understand the code, I've technically saved myself 190 seconds. That becomes a much bigger deal when your programs get more complicated.
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
Got myself in a pickel ...
Got myself in a pickel ...
Got myself in a pickel ... Got myself in a pickel ...
Got myself in a pickel ...
Got myself in a pickel ...
Got myself in a pickel ... Got myself in a pickel ... Got myself in a pickel ... Got myself in a pickel ... Got myself in a pickel ... Got myself in a pickel ... Got myself in a pickel ...
Got myself in a pickel ...
Got myself in a pickel ...
 
Got myself in a pickel ...
Got myself in a pickel ...
 
-->