Develop Reference

When creating a UserControl that uses a grid, is there any reason not to just change the base class type to Grid?

Simple question. Most UserControls inherit from UserControl, then have as their child, a grid. I've never really understood why. I mostly just go change the base type to Grid in both the XAML and the code-behind and it seems to work exactly the same, albeit with a now-simpler visual tree. And if it's a different control than grid, we do the same thing. For instance, Border is a frequent base-class choice for us.
However, when digging around in the internals of UserControl (which has the exact same interface as its base class ContentControl. Everything is inherited, the internal implementation of some of the properties are overridden for a UserControl. You can see this using Reflector or any other tool to dig into the code. However, I'm not sure any of that matters, and to date, we haven't noticed any ill side-effects of changing the base class.
So does anyone have any information that we aren't privy to about this?

(sorry to post an answer, my text is too long for a comment) Your statement about the interface of the control differs depending on your base class. Lets say you have a class Car and Car has a Steering Wheel because most likely every car in the world has a steering wheel. You implement a Porsche by deriving Porsche from Car. You add some special Porsche properties to Porsche, thats it. Of course Porsche also has a Steering Wheel -> thats what you really want.
Now you need a Garage class. You also can inherit Car to get the Garage. That does work! But makes little sense (your garage now has a steering wheel).
The same applies when you inherit your user control from Grid. The Interface of your control exposes all properties and methods of Grid (defining columns and rows, ...)! Is that what you want? Most likely not.
From a documentation and maintainability perspective it is a good idea to use a clean light weight base class for a user control and expose only those properties (and methods) that make up the Interface of your control. The first choice is still UserControl.
In other words your Grid is an implementation detail of your user control. But it is (most likely) not the Interface of the user control.
Small sidenote. Even 5 years old PCs are powerful enough so that an additional layer in the visual tree doesn't hurt.

C# How to implement a form which controls are dependant of some properties?

In my application, different controls are only used dependent of the values of properties from a particular object. The forms constructor accept this object as a parameter.
The form has always some basic functionality, no matter what properties are set of the particular object.
Now I have something like this:
if(myObject.SomeProperty)
{
myControl.Visible = true;
myOtherControl.Visible = false;
// and so on
}
At this time, the controls that are dependant of SomeProperty are buttons and tab items. However, I can imagine that in the future other controls are added to the form and are also dependant of SomeProperty.
As you might guess, I want to set this up the right way. But I don't know exactly how. How would you implement this?

There are multiple ways I can think of solving this, depending on your situation you could select the best suited to you.
1. Databinding is one elegant solution when managing the state (visibilit or other properties) of multiple control's depend on a different object. Additional details in this question
2. You could write different functions if the combination of the states is only limited to couple of cases to at most 4-5 cases. That ways you can still reason about the methods which set the state depending on the object you are depending on. Ex: Basic_Editing, Advaced_Editing, Custom_Editiong etc.
3. If the number of cases are limited you could create multiple forms (User controls) and load them on demand based on the state of the dependent property (or object you are talking about).
Just having a bunch of if else's makes your code harder to maintain, or comprehend, logically group the states so that 1. You could reason about it later, 2.Someone else understands the reason/logic 3.When there is a change required it can be localized to one of these modular methods (techniques) reducing the time to fix, and test.

I would do it like this in form constructor:
myControl.Visible = myObject.SomeProperty && !myObject.SomeOtherProperty;
myOtherControl.Visible = !myObject.SomeProperty;
....
Is it the less code and its rapidly changing.
OR
You can create separate functions that will generate controls dynamically at runtime for each form view based on object properties.

First i can see you are setting visibility on/off it means you have already controls on the form every time.. , so that not a good practice, instead create controls only when needed.
As for your scenario you can have an function like Initialize() which contains all the code for checking if showing a particular control should be shown or not and then create it and add it to Forms control collection. If any new control come to be added later you have one function to update.
A more precise answer can be given if you can provide more detail to you scenario

Sub classing all WPF base controls

Instead of using all the base wpf controls such as Label, TextBox, Grid, ect. I want to create a sub class of all these base controls and use the sub class.
e.g.
public class MyTextBox : TextBox {}
They would be dummy classes for now, but it leaves room to be expandable in-case I need to in the future. Is this recommended or is it unnecessary?

This is a text-book definition of yagni

It sounds unnecessary, unproductive, and definitely not recommended!

If for some reason you need a subclass in the future it will be much easier to simply create it then than it to do lots of unnecessary work now.

This sort of approach tends to be overkill. Where it does have its uses is when you know you will need to change the base UI controls at some point in the future. So if you were using a third party control suite then you might look at this approach, but you wouldn't want to do it with the MS controls as they are baked into the framework - you aren't going to change those!
Another approach is to ensure you follow a pattern like MVVM - this ensures that you have a UI that is nicely separated from your working code, and you can change controls with the minimum impact.

I think this is unnecessary. We can easily override the look and feel of a control using styles. In case you want to add properties, you can use attached properties.

How to figure out if other controls are constructed before OnInit

I'm making a custom control.
Basically what I'm looking for is a OnPreInit event in custom controls. I basically need to know that all of the controls that will be loaded of type MyCustomControl are constructed or not.
Ok, so basically I need to know in the constructor if the current instance being constructed will be the last.
Note: My custom control contains other controls(though this isn't guaranteed) but it will not contain controls of MyCustomControl class.
I've thought about doing an override of AddParsedObject. But if the instance of my custom control doesn't contain any controls, will this still get called?

Unfortunately the approach you're describing is "non-trivial". That means it might not be technically impossible, but so difficult to do correctly and has so many negatives/downsides that you will be better off stepping back and analyzing the larger problem for a different design. Perhaps if you re-posted articulating the end goal you're trying to accomplish, we can help you find an approach that is viable.

I hate to say use a counter, but you're either going to have to pass state information through a dedicated class (or the context,) which you could do in the constructor of the control prior to testing if you've got as many as you need, or you could do a recursive walk through Page.Controls and their .Controls and test each one for type....

Subclass built-in WinForms control?

I've come across the feature in Visual studio to auto-generate a subclass of a custom control using Add New Inherited User Control.
But I haven't found a clear description on how to e.g create a subclass of Button for instance. Apart from the actual way to do it, I'm also interested if VS provides helpful code-generation for this?

You just create your own class that inherits the Control, that you would like to subclass. For instance:
class BetterButton : Button { ...}
That is the easy part. Now you have the option to override various methods or properties, depending on what you want to achieve with your new Control. It could be anything, really. One thing I often see used is overriding OnPaint to get the control drawn in a custom way; and still getting the behaviour of the original control.
In terms of UserControls, I often see that a "parent" UserControl contains some UI logic and basic UI elements, while the subclassed controls are refinements of the parent for specific use.