I was wondering what is the best way to delete an unused control (more specifically, a timer) on Visual Studio 2010. I usually go to the control in the designer and delete it from there, but the code for the control still appears on the class form. Is it safe to delete the code associated with the control too?
As long as you don't need the logic, then yes. I assume you mean the handlers that are produced when you double click the control (such as button1_Click()). The link to the handler is removed when you delete the control, but visual studio leaves the functions in your form class in case you are using them for something else.
Delete a control through the visual editor, and the auto-generated code that creates the control and associates it with the form will be deleted as well. Code written by you, as well as event handling code generated through double clicking on the control or its events in the properties pane, will remain.
You should delete code that has to do with an non existent control. Any code that contains invalid references will keep you from building your application. Otherwise leftover code is just dead weight.
Related
When I'm making a Windows form application, and I use the toolbox and drag an item onto the form, I get a nice tool on the form, like button, listbox, etc. When I double click on the button, listBox, etc it goes to the text code part where all the delegates are. Also known as the event handlers. But what happens when I want to delete an item on the visual part of the application (the Code.cs[design] part)? I select it, then right click it and then delete it. It's off the screen. But, the problem is with all the event handlers. They're still left in the text-based code section but I don't need them there at all, and they generate a whole bunch of errors because references are gone, etc.
So, basically, I'm asking someone on the forum how to completely get rid of a button, listBox, both the visual part of it in code.cs[design] and in the code.cs part? I don't want to go line-by-line in deleting junk, I want to get rid of the button/listBox and it's accompanying code in one fell swoop.
It will delete such an automatically added event handler. But only if you didn't modify it and left it untouched with no code added. Visual Studio will not delete code that you have written. The reason for that should be obvious.
If this happens a lot then you need to get a pair of scissors and cut the mouse umbilical cord. Design first, program later.
I can't be done and it shouldn't.
You first delete the visible control and after that you delete the code stubs.
The handler assignments in the Designer.cs are then being deleted with the visible control automagically, as they were created.
Just make sure to get the order right: first delete the controls then the code.
Unless you mix those up there is no need to ever edit the designer.cs file. The code may contain important stuff you wrote. Therefore is is not deleted by studio.
You create it, you delete it! Two steps, period.
PS: The code stubs are (unfortunately) added chronologically. It would be nice if they were grouped by the controls they belong to. If you are in doubt, you can always use the 'find all references' command to find those methods buried in the past..
If you have a code stub generated, delete the method. Once that's done, Click on your 'forms view' - you will have an error screen shown.
Click on the link, and it will being you to the designer view, with your cursor shown on a specific line. Delete this line of code. Having that done, you could then delete the physical element from your designer.
I've inherited a project that has been modified in a way that is beyond me to undo. Every single control on the form is not modifiable in the designer except through the Properties window and each control has an icon in the area below (see image) in the section usually reserved for non-visible items (e.g. DataSource). How do I undo this and return the designer to a usable version without wiping it all out and starting over?
Could the controls be locked? I have run into legacy code in which the programmers have locked every single control, meaning you cannot move or resize them in the designer. If so, select them all and change the Locked property to false (you should also see a padlock in the designer when you select them, if they are locked.
If not, well maybe you can create a new dialog/form and copy the controls unto it and see if that clears things up. Another trick could be to add a second instance of the user control(s) to see if the newly added control works as expected. If so, go through the code and point all events/logic to the new control (tedious yes, but may work).
Also, you can never edit individual sub-controls of a user control in the designer for the form/control where you instantiated the user control. You must go to the designer of the user control to edit individual (sub)controls of a user control.
If the Infragistics controls are shown in the Component Tray, than there might be version differences. What you could try is to open the licenses.licx file and remove the content from there. Do you have an Infragistics controls installed on your machine? Are there any difference after setting the "Specific Version" property of the Infragistics assemblies to "false"?
Is this happening only in your existing project or the same behavior is reproducible in a new project as well?
You have to load the dll that contains the controls you can't modify in the designer.
the steps are:
right click in the ToolBox in visual studio designer (on General for example).
select Choose Items...
after a while vs load items press browse and select the dll
interested than the componet should appear in the grid. Do this for
all the dll that contains the controls you are interested.
-Make sure you have checked the component (use filter text box if you
have a lot of component loaded).
press ok.
Now you should be able to move controls in designer.
I have also seen behavior this when a user control or form is incorrectly flagged as a 'Component'.
Some manual hacking of the .csproj file may be the answer then. Open the project file in a text editor, and find the references to your control. If you find a subtype defined as:
<Compile Include="MyControl.cs">
<SubType>Component</SubType>
</Compile>
The forms designer will interpret it as such. You can change the 'SubType' to 'UserControl' to fix it.
I imagine this question has been asked and answered, but I cannot find it.
I wanted to make a simple GUI to interface to a windows 7 command. I usually use Wx, but since this was to be a windows-only thing, I decided to see if I could whip it out real fast using Visual C# 2010 Express, which I had never used before.
Things started off just great. I created a form, put a few buttons and text boxes and such on it, and hit Debug. It came up and ran just like that. No muss, no fuss. So I then designed the form just the way I wanted it, renamed the controls from "Button1" and so forth to meaningful names. But now it's a mess. By clicking around, I discovered that VC# had auto-generated two files called Form1.cs and Form1.Designer.cs. The later contains the bindings between functions and the events generated from user-clicks etc., and the former contains no-op code for those functions, for me to complete.
Problem is, the names are all still the original "Button1" and so forth, not the new ones, and the new controls I added after running the first time do not appear at all.
I want it to regenerate all that stuff afresh from the finished form. How to?
You probably don't have an actual problem, unless you edited something within Form1.Designer.cs. Provided you left that file alone, things should just work.
Whenever you double-click on a button, or use the events interface to create event handlers, the handlers are created with the following pattern:
ObjectName_EventName()
So, for example:
Button1_Click()
If you later change the name of Button1, the event handler's name is not changed, too. But it is still attached to the proper event, again - assuming you did not edit anything in Form1.Designer.cs
If you look (but don't touch!) inside Form1.Designer.cs, you will probably find something similar to:
MyNewButtonName.Click += Button1_Click;
(I don't recall the exact syntax the editor uses for wiring up event handlers; the principle is you should see your new button name being attached to the old handler name)
I am creating many usercontrols in an windows application in C# 3.5. I want to copy any usercontrol and paste it on another location of the MDIForm. Similarly in case of Cut option. I am using these three options in a contextmenustrip. And theses options are visible when I right click on the usercontrol. Can anyone tell me how It will be done at run time?
That requires giving the controls a new Parent. Explicitly supported by Winforms, they can even have no parent, quite a trick. You can do it directly by assigning the Parent property. Or by adding the control to another Controls collection, it will be automatically removed from the one it was in before.
Be careful, this flexibility comes with a price. It is also a source of a nasty leak that can crash your program after a while. That's caused by the no-parent trick, otherwise triggered by a Cut without a subsequent Paste. If you use Controls.Remove() or Controls.Clear() then the control is moved to the 'parking window', an invisible window created by the Winforms plumbing that acts as a temporary host. If you then don't either move the control to another parent or forget to call its Dispose() method then the control will live forever. Until your program runs out of resources or the user terminates the program.
The out of resources bomb ("cannot create window") typically happens after a few hours so is easily missed when debugging. You can see it in TaskMgr.exe, Processes tab. View + Select Columns and tick USER objects. Also tick GDI Objects and Handles to feel good about your program not leaking.
If you put the controls on a Panel then you can move them all together with just a single line of code by moving the panel.
You could remove the control from the ControlCollection in case of cut and cache it to add that control to some other form when pasted like you could do
panel1.Controls.Add(newPanelButton);// To add, you might have to change the control `Location` as per your need
panel1.Controls.Remove(newPanelButton);//To remove
In case of having cut/copy effect on the same form you could just change the Location of the control to the new location where you want to paste that control.
In work and in home I have VS2010 installed. But in work I have this one cool feature. On the code behind file I have two drop downs. When I select some object in the left one lets say a testButton or Default2 (a page class), on the right one I get all available events for that object and when I select an event Visual Studio autogenerates it in my code-behind file. In my home VS I actually have does 2 drop downs but they work different. I have available objects on the right one but when I select for example the testButton it shows me the aspx page and points this button :/ Should I set sommething in the VS configuration or maybe in work I have some addon which I'm not aware of? Any ideas?
This is not a VB-exclusive feature.
What you're looking for is called a navigation bar. In Visual Studio options, open Text Editor → C# → General, and you'll see an option called Navigation Bar. Enable it and click OK.
However, I believe this bar works a bit differently in VB and in C#. In C#, it only lists the existing classes and their methods; in VB, it will list all your controls and their events even if those don't exist yet.
Ok I think I've found the answer. It seems that this feature is only available when the current file is in VB.Net. In my opinion this suks :/
You need to go the design view, in the Properties box, click on Events (lighting bolt) and double click on the events you want to code behind:
(source: byte.net)
#shin is correct, this is a VB.NET only feature; Microsoft only had feedback reports dating back to 2004 mentioning this feature, so I have opened a new bug request with Microsoft regarding this; and also added feedback to Visual Studios account on UserVoice...
https://connect.microsoft.com/VisualStudio/feedback/details/688175/vs2010-c-add-page-event-handlers-to-asp-net-using-codebehind-navigation-bar-the-same-way-as-in-vb-net
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2244558-allow-c-to-add-event-handlers-to-classes-using-co
I encourage everyone who this issue effects to go and vote up & confirm this issue with them.
I dislike that C# doesn't provide such a useful time-saving function.
Up to Visual Studio 2010, only Vb.net has this feature: on code-behind page, the code panel upper-left drop down shows a control's name, and the right drop down shows this control's available events. When clicking this event we can get the code-block for this event. This feature is not available in C#.
Without above feature, we can still get a control's available events for both C# and Vb.net: We must select the control on the aspx page and choose the design view at the lower left corner, then on the Properties panel click the Event button (the lighting sign), then available actions will be shown, double-click the name of the event you want, the event code will be generated in code-behind.
It is most certainly is a VB only feature and has been reported on numerous occassions to Microsoft.
It is possible to see all the available Events in C# & Asp.net too, but not inside code window as possible in VB. But you can see all Events of any selected Control in its Property Window. Open Properties, then Click Events.
This and the feature to generate event handlers without having to switch to Design view for C# is finally coming in Visual Studio 2012. It was about time.
Even the 2012 feature is not enough. You still have to guess for Page level events (Init, PreRender, etc) and also files that haven't already been filled out for you like Global.asax, which depending on the template you started with may or may not have all the event handlers already specified.
Agreed that Event Handlers is one of the things VB has for years and years and years handled way better than C#. I can't count the number of times I've had to remind a fellow C# developer that some events do, in fact, exist.