We Keep Coding

C# how to pass variables from form to userControl and viceversa

being a beginner of C # (WinForm) I am making graphical interfaces using a form inside which there is a container panel, in it at runtime I am going to open various user controls, which for me represent the various graphical pages.
First of all I would like to know if this is a good method to manage graphical interfaces, or if there are better ones.
Then I would like to understand what is the best way to pass the data between the main form and the usercontrol pages. I usually instantiate the objects as static, so that I can also see them from the userControls ...
Thanks

Create properties in your user control so as to access the underlying data. I would advise against exposing any nested control in your user control.

Templated Control vs Custom Control in UWP. No clear answer found online

In my UWP app, my control options are User Control and Templated Control. My understanding of a User Control is KIND OF clear at this point.
I was told that a Custom Control's style/template is only instantiated in memory once, and that this only happens at the time the control is first used. That's what I want since I know the control I am creating will be used in a ListView.
In the book, XAML Unleashed, however, the author creates his Custom Control by starting with a User Control, and then simply changing it's base class. The thing is that the control he created calls InitializeComponent(). I hear that this type of class uses more memory because it is re-instatiated for each item in the ListView.
Also, I never thought that Custom Controls used the InitializeComponent() method. I thought there was simply a call to this.DefaultStyleKey = typeof(MyClass); in the constructor. What gives? I am confused on what is what...
And last, why is the style/template of the Templated Control placed in the global Generic.xaml file, instead of its own separate file (i.e., xaml file and a code-behind file pair)? If the control is supposed to be custom and "portable", then shouldn't it be totally separate from other code? I haven't found a single article explains any of these things in detail on any level.

This is something most people get wrong so I'll try to clarify a few things for you.
Memory
The whole memory thing, it's all in the Visual Tree. When you instantiate any control, whether templated or UserControl, you will use up memory with every instance because in both cases you are creating a full copy of the visual components in the template.
The templated control will create a copy from the ControlTemplate while the UserControl parses the XAML file when InitializeComponent() is called.
Memory usage will be the same if you create 100 templated controls or 100 user controls if their content is the same.
Usage
Templated controls are best for situations where you're creating a single component, like a Button, Slider, MyStarRatingInput, etc. and you're giving the users of your control the ability to swap out the template with their own. It takes a lot more effort to do this properly than UserControls because the logic has to be template agnostic and your templates have to react properly with visual state changes.
A UserControl is best for layout or views, like forms, popups, screens, pages, etc. You will not give someone the freedom to tamper with the content of your view. You may expose a few public/dependency properties if some views are reusable in a small way, but generally they are set in stone.
Generic.xaml
I honestly don't have an answer for this. Microsoft should've allowed multiple resource dictionaries to enable cleaner partitioning of control templates. Generic.xaml is a reserved filename that referencing projects will look for as the root source of the base styles of your controls. You could reference other XAML files from Generic.xaml, but that's annoying and it bloats the root of your resource dictionary. For now, you're stuck with this method.
Recommendation
If you're sharing a control library, you would want to use templated controls as much as possible. If you're building controls, views, pages, etc for your current project and they're not meant for reuse, then use UserControls.
You can still create a UserControl in your control library if you plan on owning the template and forcing all users to accept your design.
I also recommend templated controls for items that you plan on instantiating a hundred times in a single view, like a ListView. You will see noticeable speed improvement if your template is preloaded into memory instead of parsing a XAML file on every instance.

How to make dynamic user controls play nice with the designer

I have a dynamic user control that instantiates various bars and labels dynamically based on the number of members in a object group. This functionality works out very well, but the issue is that I am not the only developer on this project. I am new to the team and the "senior" members want all of the components to work in the designer. Since the components of the user control are generated at run time I am not sure how to go about making some/any of them show up in design view. Is this even an option?

I don't think that's possible, because there is no markup for the designer to show. I find it hard to believe that they would expect dynamically created controls to show in the designer.
EDIT
Thinking about it some more, why don't you just add a few hard-coded instances of the control in the markup, with the ability to add/remove. That way, the control is displayed in the designer, but you can still add/remove instances. That would probably be the best compromise in this case.

Why not give both the possibility of defining the number of dynamic controls at design time, and at run time?
In your custom control class, you can define a property that specifies the number of controls. Implement adding/removing controls in the set{} method of this property.
Make your property a "designer property". See http://msdn.microsoft.com/en-us/library/a19191fh.aspx
Keep in mind that the designer actually creates an instance of your class. Also, when a user changes your "property" in the designer, the set{} method is invoked.
I hope this helps

What are the purpose of User Controls in Visual C#?

User Controls -- Do they serve a special purpose?
As far as I can tell they are no different to forms - they have the same toolbox and features.
Are there certain times when they are appropriate to use over forms?
It would be interesting to understand what they are good for.

You use them to group a set of controls and behaviors together in a re-usable way. You can't show a control on the screen unless it's added to a form somewhere.
One good example is a textbox. It's very common to have a label next to your textboxes. You can build a user control to make this easier. Just drop a label and a textbox on the control, expose whatever your properties you want, setup the new control in your toolbox, and now you can just drop this control on your form instead of needing to arrange a label and a toolbox on the form separately.
You could kind of think of them as a panel which "remembers" what controls you put on it. And there's one more important piece. You can put code in these controls as well, and use that to also build special behaviors into your custom controls.

I have to disagree (slightly) with the selected answer. Reusability is only part of what a UserControl is for.
All Controls are reusable. Almost all controls are reusable on the same Form/Window/Panel/etc. For example, a TextBox is a control.
There are two ways to create your own reusable control:
Custom Control
Completely custom, and reusable.
Created entirely in code.
You get a bit more granular control over what your control is doing this way.
Lighter weight (usually), because there isn't anything added in for designability within Visual Studio.
In ASP.Net only: No "HTML" type file to use or edit.
User Control
Completely custom, and reusable.
Created partially in a designer in Visual Studio, and partially in code. (via code behind)
Much easier to deal with from a visual aspect.
A little heavier, as there is pre-existing code added in by the framework to support designing inside Visual Studio.
In ASP.Net only: You can change the appearance a bit simply by editing the .ascx file (basically HTML).

User Controls serve the purpose of reusing controls.
Imagine you need a search box in several pages of your application. You can create a search user control and drop it in every page where you want it visible.
So, it's nothing more than a container that aggregates reusable blocks for your pages.

Forms have a lot of extra furniture that you don't need if you simply want a collection of controls together - the minimize and maximize buttons for example. If you just simply grouped your controls in a Panel, you'd have all the event handlers on the same form as the panel - with a user control, the event handling code is in the user control class, not the form class.

You can reuse the same control on many forms. In fact all items you are using while creating windows forms are the controls. User controls are just extra controls extending controls library provided by .NET.

In ASP.NET, user controls enable you to split your page into reusable components. For example, you may want to have a search box which can be used in different places on your website, so you'd use a user control. They can also be used for partial page caching. You can cache portions of your page to improve performance.

Make an Existing Windows Form Inheritable

I didn't realize at the time I create this particular application that I'd need to reuse some of the components - some Windows forms and a class or two.
Now that I've already created the fairly complex forms inside one project, what's the easiest way to transform those forms into inheritable forms that I can reuse in other projects? Once that's done I'd like to modify the existing project to use the newly created inheritable forms.
How can I accomplish this with as little pain as possible? I'm using C# in Visual Studio 2008.

You don't really have to do anything special to achieve this. Your form is already inheritable. On any new form, just make sure the first line looks like this:
public partial class frmMyChild : frmMyInheritableForm
instead of:
public partial class frmMyChild : Form
and make any methods that you need to access from the child either "public" or "protected".
Update: one additional trick is to set the Modifiers property of each control on your original form to Protected (instead of the default Private). In the designer for your child form that inherits from this form, you will then see all of the controls on the parent form, and you can move them and resize them as you see fit (this will not affect the original form's layout).
To access any parent method from the child form, you just call:
base.MyMethod();

Just declare an empty class that inherits from System.Windows.Forms.Form and then make your "huge" class inherit from that. Once that works, start moving, a small reusable piece at a time from your "huge" class to the parent class.

In your first project, add a new "Windows Forms Control Library" to your solution
Drag the windows/classes from the original project to the new one.
fix the errors.
At this point, you now have a Class Library which you can include in your second windows project.

Bear in mind that you don't need to design your forms to be inheritable in order to use them in other projects. Inheritable forms are a PITA, and in all but the simplest circumstances are more trouble than they're worth.
If you're simply looking to design your forms to be more portable, then the biggest thing that would be required is ensuring that you do NOT expose internal fields (Controls are included in that) outside of the form. If outside code (be it in the same or another project) needs to interact with the form in some visual or behavioral way, then you need to expose functions and properties that represent that functionality, rather than the control itself.
Apart from the design of the particular form, it would likely be helpful (if a somewhat time-consuming exercise) to move these common forms into a separate control library. While you can definitely add your .exe as a reference to another project, that's not ideal (and not entirely intuitive).