Existing control event handler is not highlighted in the event list

[Yorkshireman2]

I have had much trouble with my first use of vb.net (2008) where an existing event handler is NOT highlighted in the event list. So if I select Mycombobox1 from the control list, NO event is shown in bold in the event list and when I then dropdown the event list, there are NO highlighted events in there!

I found this several times while troubleshooting events that don't fire when I expected them to.
The latest is a combobox which I bind to a datasource and then set SelectedIndex to 0 in my form load procedures; the SelectedIndexChanged event does NOT fire.
The same program written in VB6 works fine, so I thought it was a problem of VB.net. However the fact that the SelectedIndexChanged event is not shown highlighted in the combobox's event list is strange.

Each time I find this, I cut the code from the event handler, delete the event handler 'title and End Sub', then select the control and select SelectedIndexChanged event from the list to create a new 'title/End Sub', then paste my code back in.
Surprise.. now the event shows up highlighted in the list.

Why are my events not being recognised?
(It just happened again on another)

 

[softhemc]

How do you create your event handlers? If you do it manually then don't forget the Handles clause and also the parameters (s as sender, etc)

 

[jebenson]

Yorkshireman2, since you seem to be struggling with events in .NET, perhaps the information at this link might be of help:

Order of Events in Windows Forms


I used to rock and roll every night and party every day. Then it was every other day. Now I'm lucky if I can find 30 minutes a week in which to get funky. - Homer Simpson

Arrrr, mateys! Ye needs ta be preparin' yerselves fer Talk Like a Pirate Day!

 

[Yorkshireman2]

softhemc, I usually double-click a control in the form designer then if the default event that appears is not what I wanted, I look in the drop down list and select the needed one.

 

[Yorkshireman2]

jebenson,
Thank you very much, that should be very useful! I have already been inserting break points in all events and stepping through to find out what fires when and why but it does take some time.

I suppose I went through the same learning curve in VB6; it just seems vb.net has totally changed the types of events, the sequences of firing and what fires them, rather than simply improving/fixing a system that worked very well generally.
I am learning vb.net by writing-from-scratch one of my applications that has worked fine in Vb6 for years.
Events that fired in vb6 do not in vb.net and vice versa; plus the controls and properties have been changed.
E.g. a label and form had a .caption but now it has a .text (likely to make the property name the same in all controls, which is a good idea). SelectedIndexChanged definitely does not respond as it does in Vb6 and I relied on that in the original program.

However it is annoying that the things I learned over many years are now useless; a real waste of my skills and the effort I put in. No doubt many others feel this too. Unfortunately I am now looking for a job and all adverts request that you know .Net. Nobody advertises for VB6 and C++ despite there being many applications out there still running on VB6. Hence my self studying began.

 

[jebenson]

Well, if it's any consolation it does get easier as you progress up the learning curve. I too started in VB6 and transitioned to .NET, and like you I had a tough slog of it for a while. Now I am pretty well-versed in .NET, and I find it much easier to work with. So hang in there, keep banging your head against it until it makes sense, and keep posting here and we'll help as we can.


I used to rock and roll every night and party every day. Then it was every other day. Now I'm lucky if I can find 30 minutes a week in which to get funky. - Homer Simpson

Arrrr, mateys! Ye needs ta be preparin' yerselves fer Talk Like a Pirate Day!

 

[Yorkshireman2]

Now I don't feel so bad- thanks. Maybe I'll get into that Pirate thing... Arrr, I be needin some rum.

 

[WomanPro]

Create an event handler by your own, for example

Public Sub UsrCheckersClickHandler(ByVal Sender As Object, ByVal e As System.EventArgs)
your code
end sub

It's depend on what you would like to do.

 

[WomanPro]

I forgot to mention you can fire the event like that
AddHandler YourObject.Click, AddressOf My.Forms.Form1.UsrCheckersClickHandler

 

[Yorkshireman2]

Thanks WomanPro - that does seem a very useful feature of .Net, that you can customise your events and handlers. It just needs a bit of thought to see exactly what you can do with the feature.

 

[jebenson]

As long as we're talking about event handlers, here's another interesting aspect of how they work in .NET: you can have one event handler for the same event on multiple objects, and multiple event handlers for the same event from a single object, and any combination of these. For example, you could have a Button_Click event handler assigned to the Click event on several buttons:

Protected Sub Button_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click, Button2.Click, Button3.Click, Button4.Click, Button5.Click

In this case, you can differentiate among the buttons (if necessary) by examining sender.Name.

You can also do this with the AddHandler method WomanPro mentioned, instead of using Handles in the procedure definition:

AddHandler Button1.Click, AddressOf Button_Click
AddHandler Button2.Click, AddressOf Button_Click
AddHandler Button3.Click, AddressOf Button_Click
AddHandler Button4.Click, AddressOf Button_Click
AddHandler Button5.Click, AddressOf Button_Click

As I mentioned, you can also have multiple handlers for the same event on a single object:

Protected Sub Button_Click1(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click
Protected Sub Button_Click2(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click

You can of course use AddHandler to to this as well.

I will admit that I have yet to find a situation where I have needed multiple handlers for the same event, and I have tried to think of one. I included this functionality as an example of the flexibility of the .NET event handling system.



I used to rock and roll every night and party every day. Then it was every other day. Now I'm lucky if I can find 30 minutes a week in which to get funky. - Homer Simpson

Arrrr, mateys! Ye needs ta be preparin' yerselves fer Talk Like a Pirate Day!

 

[Yorkshireman2]

It happened again! I think there must be a bug in VS 2008.

I have almost finished the program and all was working fine this morning. Suddenly I noticed things were not updating as I clicked different rows of my grid. Those things are done from certain events of the grid and those events are NOT firing now.

I checked the IDE and when I select my datagridview from the upper left-hand list (controls) the right-hand list simply shows 'Declarations' in bold; when I drop down the list there are NO events shown in bold in the drop-downlist even though they are coded and were working.

The event handlers are still there in my code- I didn't touch them...BUT I noticed this time the last part of the event handler title that says, for example, 'Handles dgv1.Click has GONE.

About half of my control event handlers have done this, not just the grid. VS20008 has suddenly removed the "HANDLES" part of the titles and disassociated the events from the controls.

If I use the right-hand dropdown list to choose one of these events that has disassociated, the IDE prints out a new copy of the event handler and with the full title, including the "HANDLES" part but there is a 1 appended to the name, so it must know there is already a handler with the original name.

So WHY is vs2008 suddenly removing the "HANDLES" part of some of my event handlers?

If I cut the code of one of these event handlers and delete the old titles then reselect the event from the list and paste my code back in then it works again.

Is there a subtle setting in vs2008 that can suddenly decide to strip the "HANDLES" parts off (disassociate the event handlers) when a condition is right?
It could still be a bug in vs2008. I remember this morning when I clicked the button in the project explorer to show one of the form design tabs, it seemed to take quite a few seconds - much longer than usual - and the hourglass mouse pointer was shown for this time.
That may have been when this happened. Perhaps vs2008 rewrote some of the text files during that moment, thus causing the problem.


Has anyone else had this problem?? Do you know how to stop it happening again?

 

[jebenson]

Did you at any point cut and past the grid to move it somewhere else? Because if you did, that will remove all the "Handles" code in the event handlers, the same as if you just delete the grid entirely. Luckily it's fairly easy to correct, all you have to do it type in the Handles code, such as "Handles dgv1.Click", for each event handler.

I used to rock and roll every night and party every day. Then it was every other day. Now I'm lucky if I can find 30 minutes a week in which to get funky. - Homer Simpson

Arrrr, mateys! Ye needs ta be preparin' yerselves fer Talk Like a Pirate Day!

 

[Yorkshireman2]

Hi jebenson - No, I had not touched the grid. However, I am surprised at your revelation that moving a control causes the event 'Handles' clause to be removed! Seems a bad idea and maybe that is the culprit...

I was trying a compile option for a simpler version of the program and while testing this a few groupboxes were not resizing correctly in this version. The anchor positions seem to be relative to the design-time positions of parent/child controls. So if my design time width was not correct, the inner groupboxes were not anchoring to the right place.
The simpler version requires the right edge of the form dragging in a bit compared to the other version so I simply dragged it in and then found the groupboxes were not maintaining the right edge alignments; they were stepped over from the large groupbox.
So I kept stopping it, changing the groupbox widths slightly and running again to see if it was now correct. I have several groupboxes sat on top of a larger one, with their left and right edges aligned exactly so it seems like one large frame with sub divisions. These are anchored to left and right so they resize automatically.

It seemed like that first act of dragging the form width over a bit changed the relative anchor positions and made the smaller groupboxes' width properties just a bit larger than the large box they were sat on, and the smaller boxes' right hand edges became outside to the right of the main box.
I finally got the widths right.
Could those changes in width have caused the groupboxes to effectively become 'outside' the large groupbox instead of placed inside it as child controls?
That would explain why about half of the other controls(some textboxes), also inside the groupboxes, also lost their associations with the event handlers.

As you say, now that I know what has happened it was easy to type the handles-clauses back into all the affected event handlers. A nuisance though, just for a simple layout tweak.

This does sound like a very bad idea though by MS for Visual Studio. Once a control is created and the event code implemented, you should be able to play around with the GUI design/layout without changing anything. In VB6 you could certainly do this all day without ruining anything. Is it perhaps a bug in vs2008 after all?

 

[jebenson]

Just dragging a control to a different place, or different container, on a form will not break the Handles code. It's specifically if you cut (ctrl-x) the control then paste it elsewhere, as this essentially deletes the control and then recreates it. The same thing happens to the Handles code if you just delete a control. But just moving it around should not have caused this problem.

I used to rock and roll every night and party every day. Then it was every other day. Now I'm lucky if I can find 30 minutes a week in which to get funky. - Homer Simpson

Arrrr, mateys! Ye needs ta be preparin' yerselves fer Talk Like a Pirate Day!

 

[Yorkshireman2]

OK - thanks. Definitely nothing was cut and pasted, so this is very curious and it's happened twice now.
I won't worry too much right now but it does make you wonder if it's an obscure bug.