-
Apr 28th, 2017, 09:03 AM
#1
Thread Starter
New Member
Event Tooltips
In VS 2013, hovering over an event name gave the signature needed by the event handler to handle the event.
In VS 2015, that seems to have been changed and no event info is given. Why? I need that info and can't work effectively without it.
See the example below - top is 2015 bottom is 2013.
In 2013 the event signature is clearly given "sender as Object, e as System.Windows.Forms.ControlEventArgs".
In 2015 - it's gone. Why?
-
Apr 28th, 2017, 09:20 AM
#2
Re: Event Tooltips
I can't really test what you describe because I use ReSharper and it changes things like that but why does it matter why? If it's gone it's gone. It should be relative rare that you need to write an event handler by hand anyway but, if you do, you can always find the signature in the documentation.
-
Apr 28th, 2017, 09:27 AM
#3
Re: Event Tooltips
That said, I wonder whether it's because they've actually changed the signature of the event itself. You can actually declare events in two different ways:
vb.net Code:
Public Event FirstEvent(sender As Object, e As EventArgs) Public Event SecondEvent As EventHandler
As you can see, the first type of declaration looks rather like what you said that you saw in Intellisense in VS 2013 while the second is rather like what you're seeing in VS 2015.
-
Apr 28th, 2017, 10:02 AM
#4
Re: Event Tooltips
It looks like this is also true in VS 2017.
Sometimes MS moves in mysterious ways. Their aim is to make things "simple" for everyone, and I don't agree they always make the best choice. In MSDN documentation, it's fairly difficult to find the right signature for an event handler delegate and that's something I think belongs in the event documentation.
Nonetheless, there's a pattern to event handlers in .NET. If someone is following the pattern (and MS always does), this signature will always work:
Code:
Sub MyHandler(sender As Object, e As EventArgs)
Every event delegate should take an Object as the first parameter, and an EventArgs-derived class as the second. This is usually good enough to get Intellisense to quit whining.
When the event is named something like "Click", if it has a special type of EventArgs it should be named ClickEventArgs. Generally you can just try this and see what VS says. Not every event defines its own EventArgs, over time you get a good feel for which common ones do.
This answer is wrong. You should be using TableAdapter and Dictionaries instead.
-
Apr 28th, 2017, 10:40 AM
#5
Thread Starter
New Member
Re: Event Tooltips
Thanks.
I'm trying to make use of events on UI controls I don't have the source code for. Do I have to learn the signatures of all of the events in dozens of custom controls that I'm using?
Quite a number of the second arguments are extended versions of System.Eventargs and have properties that pass crucial info - if only I knew what class was actually being used!
Which mutton-headed mugwump at MS thought this was a good idea?
-
Apr 28th, 2017, 11:17 AM
#6
Re: Event Tooltips
Read my post again.
If the third party follows the patterns MS follows, you should be able to guess, 100% of the time, what the name of their extended EventArgs parameter is.
If they didn't, well, there's a reason the pattern exists, and why professional .NET developers follow it.
Agreed on the mugwump statement, though.
This answer is wrong. You should be using TableAdapter and Dictionaries instead.
-
Apr 28th, 2017, 11:19 AM
#7
Re: Event Tooltips
If you dimmed Button1 WithEvents then you can get to the signature by selecting the object from the left dropdown at the top, and then the event from the right dropdown.
It's possible that it's being hidden because at the time of AddHandler you don't care what the parameters are.
You can also try simply plugging in the name of the sub, then selecting the "Add stub" from the list of the error options when it shows up (note, I haven't tried that, so I don't know what it will stub out, if it'll have the correct parameters or not.)
-tg
-
Apr 28th, 2017, 12:50 PM
#8
Re: Event Tooltips
In my opinion, MS broke Intellisense in critical ways starting with VS2015. I haven't done enough with .NET in VS2017 to see whether they fixed it. Intellisense was long broken in C#. At least through 2010, it didn't give information that it should have been giving, and which was available in VB. I realize that MS wanted parity between the languages, but breaking VB rather than fixing C# was not the right answer.
One of the problems with intellisense in C# was that you'd get lousy options. For example, if you were to write:
If MessageBox.Show("What","Yo", vbYesNo) =
(I forget what the third argument is, so I borrowed one from VB6...which I may have also forgotten)
At the point you press the =, the only reasonable option is a DialogResult of one sort or another. In VB, you'd get just the DialogResult options. In C#, you wouldn't get the options until you typed DialogResult. Only when you hit the period would you see the options. What you WOULD see after the = sign is EVERYTHING else, even though virtually none of the options on the list was even plausible, and woe unto you if you couldn't remember what type the Messagebox could return.
In 2015, if you started typing arguments into a method, Intellisense would helpfully provide the type of the argument you just entered, not the next one needed. Not totally useless, but darn close. I'd say you've just found one new variation of this. They had it right....they changed that.
My usual boring signature: Nothing
-
Apr 29th, 2017, 07:15 AM
#9
Re: Event Tooltips
Originally Posted by MikeCarroll
I'm trying to make use of events on UI controls I don't have the source code for. Do I have to learn the signatures of all of the events in dozens of custom controls that I'm using?
Are you not adding these controls to a form in the designer? If so then why use AddHandler at all? You can use the Properties window to automatically generate event handlers or use the drop-downs at the top of the code window, as tg suggested.
If you are indeed creating the controls in code and do need to use AddHandler, you can still have the IDE generate the event handler for you and I've recommended this to many people on many occasions, because it guarantees that you won't make any mistakes with the signature. As a simple example, lets assume that you are generating a bunch of Buttons in code. I would suggest that you either add a Button to the form in the designer or declare a member variable of that type with the WithEvents keyword. You can then use one of the options mentioned above to generate your event handler. Finally, delete the control/field and, if necessary, the Handles clause from your event handler and you're good to go. You've got a method with the correct signature and you never had to know what that signature is.
-
May 2nd, 2017, 05:01 AM
#10
Thread Starter
New Member
Re: Event Tooltips
Originally Posted by jmcilhinney
Are you not adding these controls to a form in the designer? If so then why use AddHandler at all? You can use the Properties window to automatically generate event handlers or use the drop-downs at the top of the code window, as tg suggested.
No - I work in a weird environment where I'm making run-time modifications to .NET forms. The UI controls from the top down are all created by another application for which I do not have source code. They use their own controls which inherit from Windows.Forms but have extended features.
That's why this info is so important to me - but there is some use things to try. I just want a quick way of finding out what the signature is - we had a quick way but that has been removed.
-
May 2nd, 2017, 05:05 AM
#11
Thread Starter
New Member
Re: Event Tooltips
Originally Posted by techgnome
If you dimmed Button1 WithEvents then you can get to the signature by selecting the object from the left dropdown at the top, and then the event from the right dropdown.
It's possible that it's being hidden because at the time of AddHandler you don't care what the parameters are.
You can also try simply plugging in the name of the sub, then selecting the "Add stub" from the list of the error options when it shows up (note, I haven't tried that, so I don't know what it will stub out, if it'll have the correct parameters or not.)
-tg
Thanks. That's actually the problem - I didn't dim anything. The controls belong to another .NET application to which I have run-time access so that I can customise the form.
But I like the add stub - that might work. I'll give it a try.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|