Calling all Visual Studio gurus — when I'm working on a .ascx or .aspx file in a c# web project, the events do not show up in the properties panel unless I switch into the design view from the code view. Is this an intentional functionality of Visual Studio? Both VS2005 and VS2008 seem to work this way.
And is there any way to get the events to show up in the properties panel all the time?
I don't know if that's the way VS is 'intended to work, but yes that's a limitation. In case you've noticed sometimes clicking on the control and pressing F4 (or clicking on the properties tab) fails to load the properties for the correct control, and then you gotta select it from the list.
Sigh
That apart, if you make a usercontrol of your own, and give it an event, that event will not show up in the properties tab when you put it on a page. You'll have to capture it manually in the Page_Init event (like demonstrated by fallen888).
These days I don't bother with going to the properties tab to see an event. You can just as well type the event's name in the mark-up and then write it in the code-behind file.
Yes, that's how Visual Studio is intended to work. This doesn't help you view them in properties panel, but you can get a list of events (among other things) by typing the following in the code-behind:
"this." and intellisense should show you a list.
What I typically do is override the OnInit method and put all event handler mappings in there. So that it looks something like this:
override protected void OnInit(EventArgs e)
{
this.Load += new System.EventHandler(this.Page_Load);
this.myButton.Click += new System.EventHandler(this.myButton_Click);
base.OnInit(e);
}
If you do it using intellisense, as soon you type in "+= " you'll have the option to auto-complete that line and the event handler method's signature as well.
Yep, I wish we had a similar level of event autocompletion that we get with WPF where you can see the event name in IntelliSense and get it to automatically create a new stub event for you in code behind :(
Related
I'm running Visual Studio 2010, maybe it applies for other versions as well. When I'm in the designer and looking at the events for the RadioButton, the MouseDoubleClick event is not there:
However if I go to code view and looks at the events for the RadioButton there, I can see the MouseDoubleClick event:
It seems like VS designer is only showing the inherited events, and not the ones that is directly implemented in the RadioButton class. How can I make all of them show up in the designer?
Edit: As both Hans Passant (comment to the question) and lomed (accepted answer) points out, this is intentionally hidden. I'm using ReSharper, and that is probably why it shows up in IntelliSense, something that lomed pointed out as well in the comments of his accepted answer.
[Browsable(false)]
[EditorBrowsable(EditorBrowsableState.Never)]
public event MouseEventHandler MouseDoubleClick;
Use the Object Browser or in code-meta-data (Right Click-> Go To Definition or F12) or MSDN.
in Object Browser(F2) Set enable "Show Hidden Type And Member" (see: Did you know… You can hide or show hidden members and types in the Object Browser?, and Viewing the Structure of Code)
The way it hid the event you can see in his Signature:
[Browsable(false)]
[EditorBrowsable(EditorBrowsableState.Never)]
public event MouseEventHandler MouseDoubleClick;
Is there a way to know what parameters are needed by an event in Visual Studio 2010?
Let's say I have a DropDownList control and I want to bind a method to the "OnSelectedIndexChanged", I would do something like this
In the ASPX File:
<asp:DropDownList ID="lstMyList" runat="server" OnSelectedIndexChanged="lstMyList_SelectedIndexChanged"></asp:DropDownList>
In the codebehind:
protected void lstMyList_SelectedIndexChanged(object sender, EventArgs e)
{
...
}
Is there a way to know what parameters the method needs? (In this case, an object for the sender and an EventArgs parameter for the event.)
I know you can easily create the method by double-clicking the right event in Design Mode, but it does a mess with your code so I prefer not to use it.
Thanks!
You can find out the parameters by "going to definition" (F12) on the appropriate event, finding out what delegate type it uses, then going to definition on that. In this case the SelectedIndexChanged event has type EventHandler which is defined as follows:
[SerializableAttribute]
[ComVisibleAttribute(true)]
public delegate void EventHandler(
Object sender,
EventArgs e
)
You can also find this information by searching the web or pressing F1 and searching in the help.
I know you can easily create the method by double-clicking the right event in Design Mode, but it does a mess with your code so I prefer not to use it.
I think you should try to overcome your fear of using the designer. You are most likely wasting more time in lost productivity by not using the code generation features in Visual Studio than the potential time you might have saved by protecting yourself against the designer messing up your code.
Hardly economical in terms of keystrokes and productivity but a possibility, if you're finding the event in code to 'Go To Definition' anyway, and imagining for a moment that you don't mind using the code editor features of VS, too, is to hit the Tab key, then add the += before hitting the Tab key another two times. This will generate the appropriate delegation and method definition, which will result in you seeing the method signature.
For instance, typing the following, tabbing appropriately (twice after typing '+='):
MyType.MyEvent += new System.EventHandler(MyType_MyEvent);
Generates a method like the following:
void MyType_MyEvent(object sender, EventArgs e)
{
throw new NotImplementedException();
}
Now, the productivity reduction could occur if you don't actually require both pieces of code.
I'm new to the Visual C# designer so these are general and pretty basic question on how to work with the designer.
When we for instance add a label to a form and then double-click on it in the Visual C# designer (I'm using Microsoft Visual C# 2008 Express Edition), the following things happen:
The designer generates code within Form1.Designer.cs (assume default names for simplicity) to add the label,
then with the double-click it will add the event handler label1_Click to the label within Form1.Designer.cs, using the following code
this.label1.Click += new System.EventHandler(this.label1_Click);
and it adds the event handler method to Form1.cs
private void label1_Click(object sender, EventArgs e)
{
}
If I now remove the label only the code within Form1.Designer.cs will be removed but the label1_Click method will stay within Form1.cs even if it isn't used by anything else. But if I'm using reset within Properties->Events for the Click-event from within the designer even the label1_Click method in Form1.cs will be removed.
1.) Isn't that a little inconsistent behavior?
2.) What is the recommended way of removing such generated event handler-code?
3.) What is the best "mental approach"/best practice for using the designer?
I would approach it by mental separation in the way that Form1.cs is 100% my responsibility and that on the other hand I'm not touching the code in Form1.Designer.cs at all. Does that make sense or not? Since sometimes the designer removes sth. from Form1.cs I'm not sure about this.
1) Yes, it is inconsistent. A little.
2) I used MUCH MORE SIMPLE approach: simple wipe out all your handle code and try to compile => compiler will show you where to wipe out an event assignment. Despite of scary look, it is really safe.
3) Here is my best practices which I recommend and kind of enforce in my software department:
3a) Switch to WPF (ask for best WPF practices separately; there are a lot of other problems);
3b) NEVER ever allow Visual Studio to auto-generate event code (WPF or Windows.Forms); in case of accident use (2) as soon as possible;
3b) For event assignment use anonymous lambda:
ByButton.Click += (source, evArg) => { SomeHandler(...); };
for v.2.0:
ByButton.Click += delegate(object source, EventArgs evArgs) { SomeHandler(...); };
There are many benefits: your handlers are not bound to using specific method profile; you can put whole code inside anonymous handler is it is short enough, in lambda form you may never need to know the type of Event Arguments...
There probably is a element of safety built into Visual Studio.
For example:
Add a button A and a click event.
Reference the button A click event from another button B.
Remove button A
if the code were to go then button B would break
if the code remains then button B continues to work.
I generally comment out any code (event handlers) that break in the designer.cs file.
What is the easiest way to create code-behind (webforms) event handlers for say a button from HTML source view?
In VB.NET it is quite easy to switch to code behind page and use the object and events combo boxes along the top to select and create.
In c# those are missing (and I really don't like design view).
Make sure the Properties window is open.
Click anywhere in the element in source view.
Click the lightning symbol (events) in the Properties window.
Find the event you want to create a handler for.
Double click it.
I agree that this is less trivial with C# then with VB. My personal preference is to simply add a function with the following signature (always works):
protected void MyButtonName_Clicked(object sender, EventArgs e)
{
Button btn = (Button) sender; // remember, never null, and cast always works
... etc
}
Then, inside the code view of the HTML/ASP.NET part (aka the declarative code) you simply add:
<asp:Button runat="server" OnClick="MyButtonName_Clicked" />
I find this faster in practice then going through the several properties menus, which don't always work depending on focus and successful compile etc. You can adjust the EventArgs to whatever it is for that event, but all events work with the basic signature above. If you don't know the type, just place breakpoint on that line and hover over the e object when it breaks to find out the actual type (but most of the time you'll know it beforehand).
After a few times doing this, it becomes a second nature. If you don't like it, wait a moment for VS2010, it's been made much easier.
Note: both VB and C# never show the objects or events of elements that are placed inside naming containers (i.e., GridView, ListView). In those cases, you have to do it this way.
I was just curious how others work with this kind of WinForm code in C#.
Lets say I have a Form lets call it Form1. And I have a DataGridView called dgvMain.
Where do you put the code:
this.dgvMain.CellEndEdit += new DataGridViewCellEventHandler(dgvMain_CellEndEdit);
Do you put it in the Form1 code or the Form1 designer code?
Should this "event wiring" code go in the Form1_Load method?
The reason I am ask is... if you double click the DataGridView the IDE inserts the code:
this.dgvMain.CellContentClick += new System.Windows.Forms.DataGridViewCellEventHandler(this.dgvMain_CellContentClick);
into the designer code. Should your "event wiring" code be in two places?
Short answer is yes.
Longer answer is that .designer.cs is there for code generated by the designer. if you put your own code in there, it has a chance of getting overwritten, screwing up the design time stuff in visual studio, and lowers maintainability because nobody expects custom code to be in there.
This is a touchy subject. In 1.1, there where regions for this in your forms file, but a lot of the time, the code would be over written by the designer. I'm speaking from webforms experiance, but I would only gather that it would be the same elsewhere.
Now, you actually put the eventname in the form itself (it's one of the properties on the forms designer), and the code generator will push out the += event handler thingies in the partial class. I hate it this way, but it is what it is.
I use the Designer for all event related to Component.
I use the code for all object event.