We Keep Coding

Windows Forms Designer, Rationale behind Design > GenerateMember

In Visual Studio, while working on Windows Forms Applications a certain option can be found in the Form Design View. I'm talking about the GenerateMember option (under the Design section of the Properties Window).
The description of this option is the following:
Indicates if a member variable will be generated for this component.
So, if I create a text box tb1 using the Form Dessigner into my Form f1 and I set this option to false, then I cannot access the control within the code (neither f1.tb1 nor tb1 exists).
There should be a good reason for doing that, but I don't know what this reason could be, that's why I'm asking:
Whats the rationale behind the Design > GenerateMember option?
What things can be achieved setting this option to false that cannot be achieved with it on true?
In What situations I should preffer to hide the control setting GenerateMember to false instead of letting it to have the default value (true)?
Thank you.

When GenerateMember is set to false, instead of having a lot of private fields scoped to the Form class instance, they are created scoped to the InitializeComponent() method - meaning you will no longer have this.btnOk or this.btnCancel accessible to anything within your form.
I've figured it is, for the most part, just a personal preference. By specifying which controls you want directly visible as private fields to the rest of your form class, you can avoid getting lost in a sea of unused fields when modifying your code.
Other than that, there is no real functional difference. You could still access the controls via: this.Controls collection.

User control Anchor property issue

Context :
I created an User Control. For some reason, I want to use this control in different size. To keep the initial "Template" of my User Control when re-sizing, I use the property Anchor on my different element inside the control.
So when I create my control at design time, it is possible to me to hand re-size the control and keep the original "Template" of it.
When the control is created, it look like this :
And after re-size :
As you can see, the property Anchor work well.
The label and the picture stay in the middle.
The "?" stay to the left corner.
The problem :
The problem I have is, when the control is reloaded, created with a different size as the initial one, all the elements inside return to their initial position :
I don't know if this is the better way to do what I try to achieve. Keep in mind that I add and re-sizing the control's during the design time.
Thank you.
EDIT :
I think my problem is caused by the designer. Ex : I add my control in the designer, I re-size it, I run the solution. All is working good. But when I go to the code of the page, and then, return to the designer, the element inside the control returned to their initial position.
EDIT 2 :
Ok I have found a solution, I simply moved all the element of the User control inside a Panel. For some reason that I can't explain, it work perfectly. The control's stay at the same location.

The solution is ta add a Panel to the User Control and dock it to "Fill", then place the element inside of this panel. For some reason that I can't explain, the designer keep the location of the re-sized control's elements.

The anchoring, docking and auto-sizing of a UserControl seem to be terribly confusing. I found UserControl does not auto resize with the Form which suggests that you set the AutoSize property to False, which I did, and it still didn't correct my problem. But when I tried your solution, I also noticed there are two copies of the AutoSize property! I had set the AutoSize in the UserControl designer to False, but the Form designer where the UserControl instance was added also had an AutoSize on the instance, and that one had a different value (it was still True). When I set that to False also, then everything worked (with the panel in place). Then I removed the panel you suggested, and everything still worked. So I guess the trick is to make sure you check all the properties of the UserControl in the UserControl designer and in the form designer where the control is used. Then you shouldn't need a panel.

I've had similar problem in VS2015 project, and unfortunately - none of your answers helped. Clean and working solution was found here, in Jignesh Thakker answer.
For quicker navigation here it is how it was done in my project (c++/cli, not c#, but idea is the same):
System::Void Form1_Load(System::Object^ sender, System::EventArgs^ e) {
/* some code */
myUserControl = gcnew MyUserControl();
myUserControl->Dock = DockStyle::Fill;
tabPage1->Dock = DockStyle::Fill;
tabPage1->Controls->Add(myUserControl);
/* some code */
}

Set the Localizable property of the parent form at VS designer to false. This solves the problem at design time. (Save, close and reopen the form after switching the property)
If you need a localized application switch the Localizable property to true after finish up working at the layout and don't care about the wired representation in the VS designer. At run time it's shown correctly.
Tested in VS2013

Control's default properties

When I add a control to a form through the designer, not all properties of the control appear in the designer code. For example, when I add a ListBox the UseWaitCursor property does not appear in the designer code unless it is set to True. When I change it to False it disappears from the designer code, which makes me think that the properties somehow have defaults and don't appear in the designer code if left at default.
Can someone please help me understand how the designer works and where all this is tracked. The reason I ask is I am currently writing a class that extends a third party ActiveX control which I plan to initialize dynamically at run time. I was going through the designer code (when the third party control is added through the designer) and a lot of its properties do not appear there.

This is done with the [DefaultValue] attribute. The Control.UseWaitCursor property looks similar to this:
[DefaultValue(false)]
public bool UseWaitCursor
{
// etc..
}
So if you leave the value at False in the Properties window then the designer knows that it should not display the value in Bold and that it is not necessary to put the property assignment in the InitializeComponent() method since the default is already good. An ActiveX control will certainly have a lot of properties set at its default value as well.

Prevent from generating Form.resx

I have a form that inherits from another from. In the designer, whenever I adjust something like control size or location, VS auto-generates a resx file for that form. The resx just contains some KeyValuePairs for comboboxes, w/c are unnecessary really since these values are already defined in the parent class.
Aside from this, the designer.cs also gets update w/ inherited properties such as Text, NumericUpDown.Value, DisplayMember, ValueMember, etc, w/c again are already defined in the parent class.
I know the designer.cs is supposed to be update w/ the new location and size, but I don't want it to update other stuff that's inherited from parent class.
Is there a way to prevent this, and just let the designer update the location and size?
UPDATE:
I found that the ComboBox.Items.AddRange() gets added to the Designer.cs and .resx file due to binding logic that I have in OnLoad(). This is primarily preventing the designer to load properly when the form is reloaded on the Designer.
I modified OnLoad to run the binding logic only when DesignMode is false.
The form no longer throws errors when reloading the designer, but some of the control properties are still unnecessarily added back to the Designer.cs whenever I change any property via the property dialog.
UPDATE2:
Totally prevented the designer from generating unnecessary control properties by applying suggestion here.
Now all that's generated are control location and size.

How to fix nested winform control flicker issues

I am currently working on a program that uses a fairly complex structure of nested winform controls which changes dynamically as a user makes certain selections. To go into more detail about the specific layout of the controls would be to extensive for this question.
When ever a selection is made, a lot of updates are made to the underlying model which is controlled by the user controls. This then results in series of corresponding changes in the size/position/visibility of the displayed controls. All of these changes results in a painfully intense flickering of controls on the screen. I need to somehow fix this so that everytime the user makes a selection the screen is basically frozen until all of the control updates have completed.
I have attempted to use the Control.SuspendLayout/Control.ResumeLayout methods in many different places and ways and I can not eliminate the crazy flickering. I thought that suspending layout on the root control during the changes would fix the problem but it appears that this SuspendLayout doesn't help when child controls are changed.
Do I need to use some other approach rather than SuspendLayout? Is there a way I can debug SuspendLayout to see why it doesn't appear to be cascading to all of the child controls?

Suspend/ResumeLayout isn't your problem here. That only suspends automatic layout, the kind that is triggered by the Anchor and Dock properties. Double-buffering can't fix your problem either, that only suppresses flicker in each individual control. Your real problem is that you are updating too many controls at the same time, each will take its turn to paint itself and that takes time.
What you need is a different kind of double-buffering, compositing. Check out if the solution in this thread solves your problem.

In addition to #tommieb75's suggestion for double buffering, you can try and see if your root level controls have BeginUpdate/EndUpdate method pairs. These should help repress the repaints in between the calls.

If you are using WinForms 2+ then you can just set the 'Control.DoubleBuffer' property on the control to true (in the designer even).
With framework 2, setting DoubleBuffered sets the 3 flags : OptimizedDoubleBuffer, AllPaintingInWmPaint, and and another that I forgot, 'UserPaint' perhaps.
Also, do look at the BeginUpdate/EndUpdate as mentioned by #yetapb.

Use the SetControlStyles in the user Control, the flag is OptimizedDoubleBuffer which will prevent the flickering.