I've got a WinForm application with separate groupboxes and objects, but the code isn't sorted by groupbox and pretty messed up.
Can the code be split in 2 files or something with the objects on the same place?
EDIT:
this is my code:
how should i split it?
(i need everything with News and everything with Dir changed)
It sounds to me like you want to check out Partial Classes.
They allow you to split the code for a single class between multiple files.
You may find it easier and less problematic to use regions than trying to split out the files:
#region - TextBox Events -
private void txtNews_TextChanged() {...}
private void txtDir_TextChanged() {...}
#endregion
#region - ComboBox Events -
private void cmbNews_SelectedIndexChanged() {...}
private void cmbDir_SelectedIndexChanged() {...}
#endregion
which, when collapsed, looks like
- TextBox Events -
- ComboBox Events -
You could also consider a tool like Ora to navigate large files: http://ora.codeplex.com/ JetBrains' Resharper also has an excellent file-structure viewer.
You should probably put each GroupBox into a separate UserControl.
You could:
Split the codebehind into extra parts, beyond what the designer sets up for you so it can keep its code "safe".
Create a user control for each GroupBox, possibly even the same object set up with different names and contained controls.
Just rearrange the handlers for controls by GroupBox within the single codebehind, extracting lines from common methods (Bind/Unbind-type behavior) into groupbox-specific methods.
You can create partial classes, if you want more than one code file. It looks like:
public partial class MyClass {...}
You can, optionally, add a DependentUpon property in the .csproj (I don't know of a way to do this other than manually edit the .csproj). This joins them together in the IDE. It looks like:
<Compile Include="MyClass.Controls.cs">
<DependentUpon>MyClass.cs</DependentUpon>
</Compile>
I'm a little worried that you're talking about the auto-generated code in the .designer.cs file... you don't want to change anything that VS generated for you... if you do, you will lose all your changes the next time you change something on the form, because VS will regenerate it!
Related
I need to add attributes to certain controls in a Windows Forms project. It needs to look something like this:
C#
[Queryable()] private System.Windows.Forms.TextBox txtName;
[Queryable()] private System.Windows.Forms.DateTimePicker dtpDateOfBirth;
VB.NET
<Queryable()> Private WithEvents txtName As System.Windows.Forms.TextBox
<Queryable()> Private WithEvents dtpDateOfBirth As System.Windows.Forms.DateTimePicker
I can go in and edit the designer file to get more-or-less the desired effect, but those designer files sometimes come with the caveat that they are automatically-generated files. I'm worried that the designer might overwrite any changes that I make to the file. That said, is there a way to add attributes to controls using the designer or is there some way that I can add the attributes in a separate file?
You could test it, but I don't think the definition will get overwritten when using the forms designer. Only if you delete and re-add the control. Possibly if you copy a control the copy might not have the attribute on it. I have had to change controls from private to protected and that worked. I would think attributes would be the same.
I'm using a TabControl in my form and it made me wonder. Right now I have only two tabs and I store procedures relating to both tabs (button handlers, &c.) in the code for the main form, so it looks like this:
public partial class MainForm : Form
{
// ----------TAB1-----------
tab1SearchButtonCLick() {...}
tab1AddButtonCLick() {...}
// ----------TAB2-----------
tab2EditButtonCLick() {...}
tab2SearchButtonCLick() {...}
tab2ClearButtonCLick() {...}
}
That's not a problem now with so little code, but it might be one in the future. Is this an acceptable way of doing this? What's the alternative? I believe I could put the tabs in their own classes, but I'm not sure how I'm going to do that exactly (there's lots of controls in each tab that I'd have to pass as arguments to constructors).
You should move the contents of each tab to a separate UserControl.
Each UserControl should be a self-contained unit that gets whatever data in needs from the main form and fires events to tell the main form to do things.
The tabs have event for a reason - the tab raises the event and doesn't want to handle it.
When you use the tabs (or other objects with events) you need to write the code that handles the event.
If you really want, you can write the class in separate files so you can keep your own logic in separate files.
If you'll notice a Form is generated as a partial class by Visual studio.
That's because the design code is generated in a separate file.
You can do that yourself by declaring other parts of the class as partial in other files.
More about partial in this link
I'm working on cleaning up an app I'm almost finished with and I noticed something that made me curious as to why it's being done that way. While you can edit the .Designer.cs in your project for a form, there is a lot of autogenerated stuff in there, such as the creation of variables and controls. They have the Windows Form Designer generated code which hardly ever gets touched by me. But as I was making variables in the format I like them:
string strValue1,
strValue2;
As compared to:
string strValue1;
string strValue2;
I noticed that Windows declares the controls on the bottom of the file then creates/instantiates them in the InitializeComponent() function. Now, I knowI could take the "new" instances and put them where the declarations are and it seems to run fine. My question is what's the benefit of one over the other? Or is this the way it is so Windows can autogenerate them for us? If there's a possibility of better performance for doing it one way over another, I'd like to know. Thanks guys for the help.
Example 1:
private void InitializeComponent()
{
...
this.control1 = new System.Windows.Forms.Control();
...
}
...
System.Windows.Forms.Control control1;
Example 2:
private void InitializeComponent()
{
...
}
...
System.Windows.Forms.Control control1 = new System.Windows.Forms.Control();
Do not edit that code. It is auto-generated and the designer actually reads the code back to recreate the form in the designer. When you make changes like this, it is very likely you'll bomb the designer and your form becomes un-designable. Even if you do manage to avoid crashing it, your changes will simply disappear when you alter the form in the designer.
Anything in the region that's marked "Windows Forms Designer generated code" is hands-off.
There is no benefit whatsoever to changes like these. It generates the exact same code.
You can get some more control over stuff when its done in the InitializeComponent
If you open up your .cs file (not the designer) and look at the constructor
public Form1()
{
InitializeComponent();
}
this way you can have code execute before the controls are instantiated..
if you would just create the controls when they are declared then you would not be able to do this...
I wrote a bunch of code in the .cs file in c# for a winforms application. The application runs fine, and everything is in it's place.
Something like this:
using..
namespace Temp
{
public class Temp : Form
{
Button b1;
TextBox t1;
Temp()
{
b1.Text = "Some Text";
b1.Size = new Size(50,20);
...
}
void function1()
{
// stuff
}
static void Main()
{
Application.Run(new Temp());
}
}
}
How can I modify my code (or fix it somehow) so that the design view displays the elements in their correct positions and view so that I can visually edit them instead of having to trial/error everything.
Edit for Clarification
My application runs fine. The problem is, that I didn't use designer to create the application and so in the designer view, the app is empty. But not empty when I run it, since everything is positioned programmatically in the .cs file. My question is, how can I fix this, so that the designer shows the objects correctly.
There is no quick fix other than to redesign everything?
So to get this shown within the designer you have to know how the designer works.
For every MyForm.cs there will automatically be a file called MyForm.Designer.cs be created. Within this Designer file there will be only one function called InitializeComponents(). This function will be called within the constructor of your MyForm.cs file.
The design viewer itself is responsible for the Designer file, so any change to this file while the design view is open would normally be discarded. Also if you put some code into the designer file that is not needed be the designer will be truncated.
So the next question is, when will this truncation happen? When you freshly open the design viewer of a form, it will read in everything from the Designer.cs file without making any changes. If you make any changes onto the form by the designer the complete file will be rewritten with all the settings already read in including your latest changes.
This behaviour can be monitored if you open the designer file also as source code view, make some little changes in design mode and afterwards take a close look at the left of the source file. There will be the changes marked with a yellow or a green marker.
Now after all this stuff of informations, you can try the following procedure to get your code into the designer:
Open the design view and put some simple control onto your form (e.g. TextBox)
Save and close the design view and open the Designer.cs file as source file
Copy all your variables name of your controls at the end of the file, right below the textBox1 line
Copy all your control property settings within the InitializeComponent() function right below the property settings of the TextBox
Copy all your control constructors to the top of the file, right below the constructor of the TextBox
Save the file and open your form in design view
Select the dummy TextBox on the design view and delete it
This change within the DesignView leads to a complete rewrite of the designer.cs file, ordering all your manually added stuff the right way.
So this is the way to go. Last but not least another little trick:
Every programmer uses the using-statement to not write the whole path to every class (like System.Windows.Forms.TextBox), but the designer writes always the whole path. To make it a little easier for your copy and paste session you can also add a using statement at the top of the file. After saving and changing something in Design View all this stuff will be re-written automatically. So you don't need to add all this paths manually while your adding your stuff to the Designer.cs file.
Your best option is probably to use the properties panel in the designer to set the positions etc (or maybe just drag them?).
You could go digging around in the designer file for the form (something.Designer.cs), but this isn't a fantastic idea because it can be pretty sensitive to changing things in ways the designer doesn't expect. Having said that, it looks like you're not actually using the designer to make your form (the class would be partial, for one thing), in which case you're SOL.
In that case, you need to copy the designer code from CS to designer.cs. So that you can use designer. I think this is the simplest approach.
Looks like this file was hacked from a class file instead of being generated by the system when you create a new winform.
You need at least an InitializeComponent(); call in your constructor. However you are missing a lot of other code that is generated for you when you create the file such as Dispose().
Best bet would be to right click your project in the solution explorer and click Add Windows Form then start over.
Outline
OK, I have Google'd this and already expecting a big fat NO!! But I thought I should ask since I know sometimes there can be the odd little gem of knowledge lurking around in peoples heads ^_^
I am working my way through some excercises in a book for study, and this particular exercise is User Controls. I have cobbled together a control and would like to set the DefaultEvent for it (having done this for previous controls) so when I double-click it, the default event created is whatever I specify it to be.
NOTE: This is a standard User Control (.ascx), NOT a custom rendered control.
Current Code
Here is the class & event definition:
[System.ComponentModel.DefaultEvent("OKClicked")]
public partial class AddressBox : System.Web.UI.UserControl
{
public event EventHandler OKClicked;
Current Result
Now, when I double click the the control when it is on a ASPX page, the following is created:
protected void AddressBox1_Load(object sender, EventArgs e)
{
}
Not quite what I was expecting! So, my question:
Is it possible to define a DefaultEvent for a UserControl? Is it a hack? If it's [not] supported, is there a reason?
Side Note: How do we put underscores in code? I cant seem to put and escape char in?
Here is a possible answer, without testing (like martin did).
In reflector, you will see that the DefaultEventAttribute allows itself to be inherited.
In reflector, you see that the UserControl class has it's default event set to the Load event.
So the possible reason is that even though you are decorating your user control with the default event of OKClick, VS might still be thinking that the default event is load, as it's being inherited from UserControl whose default event is Load.
Just a high level guess at what might be happening.
OK, I checked this out, Inheriting from WebControl rather than UserControl.. All worked fine.
Looks like Darren Kopp takes the crown for this one! Thanks for the input!