Board index » Visual Studio » Is there a good way to write for events under VB?

Visual Studio23
Hello, experts:



I have a beginner's question. I would like to know if there is a sensible way

of writing event handlers under VB. For a Numeric Update control called

"nudSpin", this is apparently wrong:



Private Sub nudSpin_MouseUp() Handles nudSpin.MouseUp

' my code

End Sub



I get an error which says "Method 'nudSpin_MouseUp' cannot handle Event

'MouseUp' because they do not have the same signature."



OK, so what is this signature stuff about? If I create the method header the

old fashioned (VB6) way (by clicking on the control), I get:



Private Sub nudSpin_ValueChanged(ByVal sender As System.Object, ByVal e As

System.EventArgs) Handles nudSpin.ValueChanged

' place code here

End Sub



which is not what I want. I don't want a response to a changed value, I want a

response to someone releasing a mouse button while using the control. If I

changed the "Handles" modifier to "Handles nudSpin.MouseUp, I get the

signature error again.



I don't get this signature stuff. I am not using prorpietary controls, and

after reading warnings on this newsgroup, I have avoided ActiveX controls

(even though VB tells me they are available). The controls for this program

appear to be native to Microsoft VB.NET. Why can't I handle the events I want

to handle?



Thanks for any light you can shed on this



Paul King


-

By looking around the documentation, it looks as though the initial problem

was overcome (by cutting and pasting), but not the larger problem of writing

methods generally.



It seems that fussing about "signatures" is Microsoft's way of saying the

parameters don't match the prototype. The word "signature" is too confusing,

since the same word is used in many other contexts (even in this newsgroup).

That is, nothing I was using needed any digital signing.



However, the question remains, if I need to write a specialised method, do I

need to memorise all possible syntaxes to all events for all controls, do I

cut and paste the syntax from the Help dialog, or is there something more

efficient? Obviously, clicking on the control doesn't give me the sensible

methods it used to give me.



Paul King



On Sat, 23 Jun 2007 15:18:13 -0400, Paul King <xogblog@hotmail.com>wrote:

Ok all events that are possible to code against have already been defined.

You do not get to say what that signature is. you must match by parameter

quantity and type.



If you wish to handle the Mouseup event then there are 2 ways to do it.



1.>Define the instance of the control/class that you wish to handle events

for using the WithEvents keyword.

This will already have been done for you if you dragged the control onto

the form in the forst place.

Once done you can select the control from the dropdown in the top left of

the IDE and then select the event from the next dropdown in the top right.

This creates the Stub signature where you can fill out you handling code.



This can be done manually if you prefer. All you need to get right is the

params with their types and the handles keyword together with its Object.event

syntax at tyhe end.



2.>Skip the "WithEvents" and "Handles" aspects but still code with the correct

params and their types. Then Attach the coded method to the object's event

using the AddHandler syntax

-------------------------------------------------------------

AddHandler <Object>.<Event>, Addressof <ProcName>

-------------------------------------------------------------



Hopefully this should set you on the right track.



If you need anything else... just ask :)



--

Rory





-

"Paul King" <xogblog@hotmail.com>wrote in message

The signature is the set of parameters sent by the assembly which is raising

the event. The first parameter is the control which is sending the event

and the second parameter depends on the type of event. For example a click

event for a button does not send any other info so the second parameter is

not used. For other events it will send information pertinant to the event.



When you double click a control in the designer you will get the "default"

event created. Just go to the list of controls in the dropdown at the top

of the source code, select the control you want to create an event for and

then from the dropdown beside it select the event you wish to create code

for. It is really not much different than VB6.



Lloyd Sheen



-

On Sat, 23 Jun 2007 19:36:20 +0000 (UTC), Rory Becker

<RoryBecker@newsgroup.nospam>wrote:

Thanks. I forgot about this from VB6.



Paul King

-

Paul King wrote:



There is a standard convention for event handlers that permeates the

entire Framework - whether you regard this as "sensible" is another

matter entirely.



The Event model changed /completely/ from VB6, which used what is now

referred to as an "auto-wireup" model. You /used/ to have ...



Sub nudSpin_ValueChanged()



... and /just/ because this method /happened/ to have the name of the

Control, followed by "_", followed by the name of the Event, the VB

compiler "hooked it up" to the ValueChanged event on the control,

nudSpin. This was the /only/ method that could handle that particular

event.



Now, in Brave New World.Net, we have the "new", "improved" event model,

using complicated signatures and the Handles keyword.



Sub nudSpin_ValueChanged( _

ByVal sender as Object _

, ByVal e as EventArgs) _

Handles nudSpin.ValueChanged



In every event handler, "sender" is the Control (or other object) that

raised the event, whatever that happened to be, and "e" is an

EventArgs-derived class that contains useful information about the event

(or EventArgs.Empty, if there's nothing useful to tell you).



However, in this mew way of thinking, you could just as well have ...



Sub fred66( _

ByVal sender as Object _

, ByVal e as EventArgs _

) Handles nudSpin1.ValueChanged _

, nudSpin2.ValueChanged _

, nudSpin3.ValueChanged



... one routine handling the ValueChanged event from three /different/

spin controls.



Where we just used to have method Names, we now have Signatures - the

combination of the method Name and all its arguments. This is how

overloading works. Compare the signatures for the two Events:



Sub nudSpin_MouseUp( sender as Object, e as MouseEventArgs )

Sub nudSpin_ValueChanged( sender as Object, e as EventArgs )



Different signatures, different methods.

You can't "cross-wire" one event into a handler for another - the code

in the event handler will probably rely on certain properties being

present in the event arguments, "e", and if you send it the wrong Type

of event argument, that code will fail - the compiler is trying to

protect you from doing this when it complains about methods not being

able to handle one another's events.



It /does/ take a bit of getting used to...



You can; it's just a mite more fiddly to do that it used to be.



HTH,

Phill W.

-